ABSTRACT
The humble <table> element is a controversial element.
Let me explain some basic history. The Web was started by a bunch of geeks who wanted to share technical and scientific information. They didn’t have much vision of the overblown behemoth it’s become since 1994.
WHAT IS A TABLE FOR?
A fairly principal way that data is described is as tabular data. It is shown in rows and columns. Rows usually describe a succession of data collection points, and columns represent the values of data points:
| Time | Mom | Dad | Timmy | Lassie |
|---|---|---|---|---|
| 4 AM | In Bed | In Bed | In Bed | In Bed |
| 5 AM | In Bed | In Bed | In Bed | In Bed |
| 6 AM | In Bed | In Bed | Going to Play in the Wellhouse | Whizzing on the Carpet |
| 7 AM | Stepping on Suspicious Wet Spot on the Rug | Shaving | In Well | Looking for Timmy |
For this, they developed the <table> element. This element is very old. It has been a part of markup since the very beginning. It is supported and understood by every browser out there. It was designed to present data in an ordered fashion, and, now this is important, to form itself around the content it contains. Got that? The <table> element adjusts to fit the content it contains. I’ll get back to that later, and you’ll see why this is so important.
Now, as the Web became more visual and creative, some smart geeks figured out how to use the <table> element to control the layout of a Web page. Basic HTML did not have provision for positional layout control. It was all about displaying text; from left to right, top to bottom. Images could be stuck in there using the <img> element, but we couldn’t do things like columnar layout:
| Side Nav Area | Top Navigation/Banner Area | |
| Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Cras scelerisque, nisi ac feugiat malesuada, magna lorem faucibus ligula, vitae gravida odio ante tristique augue. Sed urna. Maecenas vitae lectus. Phasellus velit velit, pulvinar quis, volutpat at, aliquet eu, nulla. Vivamus congue ultrices sem. Mauris sit amet ligula. Maecenas nisl. Integer augue. Nullam ante ipsum, ultricies vitae, molestie eget, blandit vitae, pede. Morbi mauris justo, pellentesque sed, condimentum non, facilisis ac, pede. Vestibulum sit amet turpis. Proin mollis, felis id aliquet consequat, velit sapien euismod turpis, eu rhoncus lacus justo at felis. Nulla dignissim erat nec urna. Vestibulum pulvinar. Ut vitae nisi a erat accumsan venenatis. Mauris non justo in lacus porta placerat. | Morbi varius, lacus sed aliquet suscipit, tortor eros sodales sem, a laoreet augue leo quis ipsum. Nulla nunc. Pellentesque sagittis, diam eu tempor consectetuer, diam quam luctus nibh, non mollis est leo eu tortor. Sed semper odio nec dui. Vivamus lectus. Nulla purus massa, feugiat ac, imperdiet id, porta ac, purus. Nunc gravida enim a velit. Quisque interdum nulla id enim. Ut iaculis tortor id ipsum blandit bibendum. Praesent sodales. Aliquam erat volutpat. Curabitur id risus et tortor interdum rutrum. Nam quis dui id nibh semper tempus. Vestibulum gravida posuere purus. | |
| Bottom Navigation Area | ||
Basically, they made the entire page body into one big table, and then used the various sections to hold the page elements and to control the positioning. Not anywhere near perfect, but it worked, and worked well. Table-based page structure became the standard way to design Web pages for a decade. Many, many sites still use it. It gives you very good control of your layout, makes sure that the page content won’t break the layout and is understood by every browser out there.
There is a myth that table-based layout is different from CSS-based layout. Not true. Both of the tables I showed on this page are completely controlled by CSS. It is inline stye CSS, but CSS nonetheless (The only reason I use inline styles is to keep the examples as self-contained as possible). You can control <table> elements with CSS every bit as thoroughly as you can any other element. Tables have a different display mode, and have a lot of inherent styles, but they are standard HTML elements, and, as such, have style properties that can be manipulated with CSS.
The actual choice is between <table> elements and other block-level elements, such as <div> elements. I’ll go into more detail on this in the next posting. I just want to introduce the <table> element here.
When you use <table> elements, you are accepting some fairly significant limitations. The biggest one is that you can’t easily reposition table cells around the page. A <td> element must always be in a certain place on the page, relative to other parts of the table. This greatly reduces the flexibility of your page design.
Another limitation is that most browsers won’t render a table until they have received all the data that is contained in that table, or the table appearance may change as more data is loaded. This can give the appearance of a slow page load.
And finally, because tables react to their content, they are not so easy to control. Block-level elements can have their appearance in relation to the page and other elements controlled very rigidly. Not so tables. If the content is too big for a table cell, it will stretch to accommodate that content, which could affect the entire appearance of the page.
Next, we’ll go into table-based layout in a bit more detail, and compare it with block-level layout.