The underappreciated <table>
You were 16 years old and had a beater of a car, but it did the job. It got you from Point A to Point B. It wasn’t flashy, but it did the job.
After a few years, you started to get a little self-conscious about your starter car. Some jerk told you that it wasn’t fashionable enough. You went out and bought a flashy car; this one had GPS navigation, heated seats, and cupholders in the back. You were happy to be fashionable.
But then you started to get this gnawing feeling: maybe the old car wasn’t so bad. Maybe “Point A to Point B,” as unsexy as that is, ain’t so bad. Maybe, in certain situations, that old thing actually worked better than your new little coupe.
<table> vs. <div>
And so it is on the Web. We started with tables, and tables did the job. Then L. Ron Hubbard Jeffrey Zeldman came along and told us we were doing everything wrong. The CSS zealots advocates brainwashed convinced everyone that tables were always inferior for layout. And not only that, they told us that tables were wrong.
Well, they were wrong. The beater car is better. Sometimes.
Here’s why. Do you know what a royal pain in the ass it is to create the layout below in CSS?
| Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Etiam eget est id mauris consectetuer feugiat. Proin ac lorem. Nulla id ipsum. Curabitur iaculis. Fusce in risus. Ut vel diam | Class aptent taciti sociosqu ad litora torquent per conubia nostra, per inceptos hymenaeos. | Morbi molestie nisl sed arcu. | Aliquam dignissim, pede in porttitor nonummy, justo erat interdum orci, tincidunt sodales dui sapien ut urna. Nam risus. Quisque facilisis viverra ligula. |
I’ll give you a hint: it’s a big pain in the ass. I’ve had to do a lot of things like that lately, and sometimes, practical concerns far outweigh philosophical purity. At some point, taking the moral high ground of using CSS leads a person into low-oxygen altitudes. Maybe that explains the CSS propaganda.
The “CSS vs. tables” myth
Here’s the other problem. All of L. Ron Hubbard’s Zeldman’s propaganda advocacy has confused a lot of people. They think that “CSS” and “tables” are opposed. I’ve talked to two people recently who are learning CSS, and they’ve been totally taken by the “tables are evil” mantra. Let’s get this straight, once and for all:
CSS and tables are not opposites. CSS applies to tables.
In fact, some great CSS Zen Garden-like examples of table-styling via CSS exist. Stylesheets apply to <table>, <tr>, and <td> just as well as <div> and <span>. Let’s get that straight, once and for all! View Source on this page and see how I applied styles to the table example above. No inline HTML attributes to be found!
Don’t get carried away
You’re probably going to misinterpret this article. Don’t. CSS+DIVs is the way to go for macro Web layout. But in micro applications, tables can be practical, useful, and just a helluva lot simpler. That’s my point.
April 15th, 2006 at 9:14 pm
BLASPHEMER! (j/k)
Tables aren’t bad or wrong. Use them when you have tabular content to be presented.
I hear you though. Sometimes, you have to go around your ass to get to your elbow in order to do it “right.” Tables are sometimes way faster to get working and (possibly) provides more browser compatibility.
I don’t like the “div” tag much either, I’d rather it be something more, well, meaningful–perhaps <container> or <block> As long as we’re whining here, it’d also be really nice if making adjacent div’s wasn’t so wonky.
April 19th, 2006 at 9:57 am
Totally agree… wish I could have commented sooner. I joke that I’m the last hold out for the table model.
Obviously.
I think the point here (or at least mine is) that though tables are supposed to be used strictly for tabluar data, it is much easier to use tables for layout because the CSS model isn’t quite as powerful yet.
I challenge anyone to produce http://www.northwestern.edu without a table, in particular the news/events/banner row. It can be done with fewer tables, but I don’t think you can get rid of them altogether (rules: no JavaScript, news and events must have equals widths and equal heights that expand with text).
You can strike possibly, that statement is a fact. I refer you to Netscape 4.7 and IE 5 for the Mac.
This is the beginning and end of the problem. If making adjacent containers was simple (see my example above) we’d be in business.
While we’re at it, if I’m floating two <div>s in a container <div>, wouldn’t it make sense if the container’s height matched the taller of the two children. I think this defeats intuitive sense: how can something large be “in” something smaller?
April 20th, 2006 at 1:28 am
Caveats aside, it wouldn’t be hard to replicate that entire layout sans-tables. To deal with your rules, it’s a simple kludge to use at least one table for that case without needing to rely on tables for the rest of the design. If the current behavior of NW’s homepage is not negotiable, then 1 table is needed.
Compared to using only tables? Depends on how you want to define “powerful.” Personally, I think power lies in lean, semanticaly correct code and commonsensical stylesheets that rely on inheritence. To me, the benefits of tableless design outway the tradeoffs.
I use “possibly” because divs and CSS aren’t going to meltdown in NS 4.7 or IE5 on a mac–they may not render pixel-perfect, but the content should still be well intact. And unless you continue to use HTML 4.0, image slicing and spacer GIFS, I assume you’re using some sort of table / css hybrid. This will cause just as many browser compatibility problems as using no tables at all. It’s also debatable how much weight to give such out-of-date browsers. Most web pages built in the past 5 years won’t look “correct” on them, not to mention they comprise an extreme vanishing superminority of all potential visitors.
Basically, use tables when you need them but not for entire layouts or to bail out ignorance or laziness.