Another CSS vs. tables debate
I can’t believe these debates are still happening. A number of blogs have been spreading around this rant about why CSS is bad at layout, and the old debate of CSS vs. table layouts has been reignited.
The one big thing people seem to be forgetting is that CSS can do table layouts without table elements! So the main benefits of table layouts are possible in pure CSS layouts using divs or other elements. The main problem with CSS table layouts is that Internet Explorer 7 and below didn’t support those parts of the CSS specification (while all other browsers have supported them for a long time now). But that’s a shortcoming of Internet Explorer, not CSS, and Internet Explorer 8 will have support for CSS table layouts.
I’m not saying that CSS table layouts are perfect. There are two other significant shortcomings of CSS table layouts:
First, CSS 2.1 doesn’t provide for a way to specify that a cell should span multiple rows or columns (as HTML’s rowspan and colspan attributes allow). In most cases, this limitation can be worked around by mixing the CSS table layouts with other CSS layout methods.
Second, CSS table layouts usually require lots of nested divs. It doesn’t require any more elements than HTML table layouts require, but it’s still quite bulky compared to other CSS layouts, and it demonstrates how dependent CSS still is on the underlying markup. CSS 3’s pseudo-element model will help mitigate this issue somewhat.
However, if the argument is that CSS doesn’t support the kinds of flexible grid layouts that HTML tables support, that argument is simply incorrect. Sure, CSS isn’t as markup-agnostic as it could or probably should be, but the use of HTML tables for layout is not a better solution.
February 5th, 2009 at 23:34 UTC
Actually, I’ve found that more often than not, using plain HTML semantics is enough to cover 95% of CSS’s markup needs (create your navigation menu with lists, you can style the lists like tables and use them for rollover menus etc.); extra markup is actually required only to create nice effects like rounded corners or drop shadows. But even then, using :before and :after reduces such needs quite a lot, and for those browsers that don’t support these pseudo-elements, a bit of Javascript to add elements to the DOM instead will work very well (and will be much easier too: if, for instance, I want to add nice effects to all my h3 on a page, modifying the HTML code directly would be clunky while I could simply tell the Javascript engine to detect all said h3s, add an element before each of them’s first child and after its last one, and style these elements like I would the :before and :after pseudo-ones; there, done, no HTML markup added).
In fact, the only time I added specific markup to a page in the website I maintain was not because of style (well, not completely) but for Javascript concerns; and because said elements were used to create an almost Flash-like experience (yes, the index page menu and animation). Which still remains perfectly accessible with CSS turned off and Javascript disabled. And I shudder how much markup I would have needed to obtain the same effects and layout with tables. Yeugh.
No, the ones still asking for tables-based design are those who can only think about “I want my site to look like this” instead of “I want my site to display that” (as in, the former think about boxes where you stuff things until they burst, but things are where they belong; the latter think about what things actually mean and/or represent). They also don’t know how awkward it is to handle tables in Javascript.
Sure, as you say there are way to position elements in a tabular way using CSS 2.1; there are improvements in that coming in CSS 3. And yes, it’s true that CSS isn’t quite rich enough to provide professional print-ready layouts. But damn, I haven’t yet found a case where forgoing the use of a table for a bit of mind juice and a CSS solution didn’t actually yield a more elegant, more flexible and more powerful result that didn’t pollute my HTML markup with unnecessary tags…
Posted using Mozilla Firefox 3.0.5 on Linux.
February 7th, 2009 at 20:59 UTC
Most of the arguments seem to boil down to “it’s too hard”.
The presented three-column CSS lay-out has problems, indeed. But it should be pointed out that it is kind of a hack. Using floats like that wasn’t what it was designed for. With wider support for inline-block we can finally leave it behind us.
As for this whole HTML semantics being bound to how they’re rendered… What a load of nonsense. The reasoning the author uses to say this is plain weird, and no matter how much commenters try to explain to him how it’s wrong, he just doesn’t get it.
Posted using (Unrecognized) 1.8.1.19.
February 12th, 2009 at 21:13 UTC
There are so many things wrong with that rant, it would take pages to sift it all out. I couldn’t even bring myself to finish reading it.
Early on, the blogger declares that if CSS is too hard for the apparent army of geniuses at the design firm Maxdesign from which he drew his faulty 3-column layout, then it must be worthlessly impossible.
A look at Maxdesign’s site however, is revealing. The entire firm seems to consist largely of one Russ Weakly. Does a solid business have their top manager’s personal e-mail address as their main contact, as on this page? A look at their promoted sites, or at least the thumbnails of same suggest they stick to two or three base layouts and the rest is Photoshop.
I’d hardly place them on a pedestal as being any kind of world class web design firm. And I certainly wouldn’t stake my own credibility on such a perception.
Posted using Mozilla Firefox 3.0.6 on Windows.
February 15th, 2009 at 12:38 UTC
Actually CSS allows table layout with less elements than HTML tables do.
You can simply make an element (and it’s siblings) display: table-cell and CSS creates anonymous boxes for table-row and table.
That’s good for the simple 3-column-layout.
If you want more rows you need display: table-row, but still no table.
Anyway, only time will tell how CSS Tables will find their way into the web in the next years.
Posted using Mozilla Firefox 3.0.6 on Windows.
February 18th, 2009 at 09:45 UTC
@Daniel: while your tip on table-cell (and table-row) actually works, I would personally not use it: it’s a hack you’re forced to use, like in HTML using a bunch of TDs to create inline-blocks… In practice, you would need to give all elements you would want in a table, a specific class (say, 3 paragraphs) and then declare said class to have display:table-cell. Semantically, these elements have something that takes them apart from the page’s body, so they should be marked as such – with a DIV. That, or use a restyled UL/LI combo instead (it may be better semantically)
The ‘only’ problem one has to solve, is that we now have a ‘table’, and ‘table cells’; but no table row. It is also a limitation of HTML, that you can easily set up rows, but not columns. That’s, personally, what I want most from CSS3.
Posted using Mozilla Firefox 3.0.5 on Linux.
February 21st, 2009 at 10:02 UTC
@Mitch 74:
Take a look. It is defined what an engine has to do if any part of a table is missing while it’s laid out.
Yeah, one can hope for many things to come in CSS 3.
Posted using Mozilla Firefox 3.0.6 on Windows.
February 23rd, 2009 at 10:11 UTC
…my bad.
I stiff feel uncomfortable not having a semantic element defining where the ‘table’ (or table body) should be in the HTML markup.
Posted using Mozilla Firefox 3.0.5 on Linux.