Impossible CSS gripe #2

Wednesday 29 October 2003 — This is nearly 21 years old. Be careful.

Here’s another CSS gripe that I don’t think we can do anything about. What the heck is wrong with tables as a concept? I understand why we want to separate content from layout. I can see that we don’t want to overload the poor <table> tag with both tabular data display and grid layout, because that’s poor semantics.

But everyone understands tables. Any designer out there can take any old layout grid, no matter how wild, and tell you how to create a table to display it. So why can’t CSS use those concepts for layout? Why did separating the layout from the content requiring using entirely new concepts to describe the layout? All the HTML authors understood how to write tables, and all the browsers understood how to display tables. Why did CSS leave tables behind?

CSS could have been designed to separate content from layout and at the same time, use table concepts to describe the layout. There’s no incompatibility between the two. Sure, tables wouldn’t do everything: you can’t do floated pull-quotes with tables. But they are great at page-level grid layouts. Why couldn’t CSS have kept those concepts?

Now we have all sorts of clever people outdoing each other to try to describe conceptually simple layouts in CSS. These people could be putting their energies to productive use, but instead are doing the web design equivalent of translating “The Cat in The Hat” into Sanskrit. To what end?

Why couldn’t CSS have let me describe the grid of the page with familiar <table>-like constructs? Doug Sauder asked these same questions, and proposed a <grid> tag. I’d do the same, but keep it separate from the content, to keep the main CSS goodness. Three-column layout with a 100 pixel left column, and the other two columns splitting the rest 70/30? With a header and two footers? No problem:

<grid>
  <tr colspan='3'><td id='head1'/></tr>
  <tr>
    <td width='100px' id='left'/>
    <td width='70%' id='center'/>
    <td width='30%' id='right'/>
  </tr>
  <tr colspan='3'><td id='footer1'/></tr>
  <tr colspan='3'><td id='footer2'/></tr>
</grid>

Even the hippest coolest proponents of modern web design admit that tables do some things better than CSS. Why did CSS throw the baby out with the bath water?

I know this seems like an angry rant, but I really want to know. Why are floated divs and the other CSS constructs better than tables as a layout mechanism?

Comments

anders 9:26 AM on 29 Oct 2003

this is why CSS has 'display: table'. IE, naturally, doesn't support it, but in other browsers, you can do *exactly* the same layouts as tables in CSS without using table tags. see: http://www.w3.org/TR/REC-CSS2/tables.html#q2

Jonathan Richardson 1:14 PM on 29 Oct 2003

What is CSS?

Nick 1:34 PM on 29 Oct 2003

Tables are not banned when you use CSS? You can still use tables, and style them using CSS, it is just the community who does not want you to use them, and for good reason.

When you use a "grid" for layout in your html, you can not change your layout via CSS.

Look at your example, say you "left" column contains a navigation list. How do you move your nav list to the right side using only CSS? You can't. How do you change your nav list from a vertical to horizontal list? you can't.

The point is that using the grid makes it much harder to maintain your site. The whole point of CSS is to make it so that you can style many pages with one CSS file. But when you use a grid you have to modify every page that has a grid in it.

That is why tables are frowned upon. Even with that said, many sites still use tables, and the table tag is still valid markup.

Zubin Tiku 2:55 PM on 29 Oct 2003

Tables are inherently limited for layout purposes because when you work with tables, anytime you have an object (whether it be text, image, etc.) in a table its position on the page is directly connected to the table. When you want to reposition the object you will likely have to modify the entire table so that the rest of the layout is not affected by your movment of that one object.

With CSS, the layout of objects can be relative to each other, which allows for *MUCH* more flexibility.

Ned Batchelder 3:22 PM on 29 Oct 2003

Nick: we have to separate two concepts in CSS: the separation of content from style, and the specification of style using floated divs, etc. Why can't CSS separate style from content AND let me use table concepts to layout the page?

Zubin: I agree that CSS is great at treating objects separately. I disagree that all pages need that separation. Tons of designers are looking to produce layouts that naturally fit into table concepts, and they don't need to move everything independently. For the most part, they think very carefully about moving things around, and want to control where things go as a result of a change. I don't think designers mind that degree of control. After all, we're dragging them kicking and screaming from tables to CSS. Why not have CSS provide them with the language they want?

Mark 5:20 PM on 29 Oct 2003

Considering that a lot of pages are dynamically generated, or created from templates, i don't think it's a strong argument that having to change the code within the page is a problem.

Both Tables and CSS are powerful tools, and it would be real nice if there were better [universal] support for CSS within Tables and table elements. Last time i checked MSIE ignores the "margin" attribute on TDs [and the "padding" attribute on IMG] see http://www.jujusoft.com/log/200210152327.html

[i was unaware of that "display:table" CSS stuff.... very interesting]

freddyMac 5:48 PM on 29 Oct 2003

yo, lay off, Zeldman's gotta eat too! On the real, many arguments that I see for CSS only layouts mention display in cellphones and PDAs. Swell, but it seems to me to be a relatively small percentage of sites that get built have that need...

Roger Cornwell 5:50 AM on 30 Oct 2003

If you use tables you should consider how they are going to appear to someone who is using a screen reader, probably because they are blind. These tend to read rows before columns, so if you want to lay out the web page so someone reads all of column 1 before moving on to column 2, then you should not use a table because it will be very confusing to someone who cannot see the screen but is relying on alternative technology.

Ned Batchelder 7:08 AM on 30 Oct 2003

I understand the need for screen readers. That's why I'd keep the content separate from the style, just as CSS does today. In my table example, the cells are all empty, and have an id attribute. The actual content would be in divs with the same ids. The divs could be presented in whatever order made sense for style-less browsers, including screen readers.

Stan Rogers 3:34 PM on 30 Oct 2003

Ahh, I see -- you want a reference grid to hang things off of that would act pretty much like an HTML table without actually being one. CSS as XSLT, while leaving the actual markup alone. That would be a Good Idea, and entirely within the spirit of the First Amendment (guaranteeing that Document shall pass no Tag establishing a Table when the data is not, in fact, tabular). Where were you when the Working Group was working? Oh, yeah -- it had something to do with, like, collaboration platforms or something, didn't it?

SSI Developer 6:58 AM on 31 Oct 2003

This is an endless arguement.

CSS layouts have fallen short of their intended goal.
Yes tables are currently better for layouts but mainly because browsers don't have the problems with them that they have with CSS.

I still prefer tables for layout even though I offer free CSS templates. CSS will be the way in future and I think they eventually will be better than tables, it'll just take a few years to get there.

Aaron Boodman 4:31 PM on 31 Oct 2003

I'm with you Ned. I actually have always wished that the W3C would throw away the layout pieces of CSS and replace it with something like XUL(which is basically what you have described).

And speaking of CSS as XSLT, you haven't hit on my number one gripe: the fact that there's now two w3c-approved ways to select elements in a DOM (CSS selectors and XPath)?

I think it's clear that XPath is about ten trillion times more powerful than CSS selectors. So why are we still getting updates to this clearly inferior language.

blech.

David Mullen 6:18 PM on 31 Oct 2003

What I don't understand about CSS positioning is that (a) it seems to fly in the face of all previous wisdom regarding the aesthetics of layout, and (b) no one has yet, to my satisfaction, explained why this is a Good Thing. For example, the Web Style Guide has always recommended using a design grid to "establish a consistent, logical screen layout". They don't say anything about tables or CSS at that point; they're just talking about aesthetics.

Then there's Lynda Weinman (Aesthetics of Layout): "Though this might sound like I'm now encouraging rectangle-itis, I do advocate the use of a grid in your design. The grid itself is not a visible component—it just helps you align your text and images so your design has a sense of security and order." Again, she's arguing from a purely aesthetic standpoint.

So we're back to Ned's question, rephrased somewhat: If it's a good idea to use an *imaginary* grid to lay out your pages, then why is it a bad idea to use an *actual* grid (i.e., a "grid" element) to mark up those pages? I, for one, don't see any compelling reason to abandon the whole grid concept, just because some cooler-than-thou "designers" have decreed that table layouts are to be henceforth "frowned upon".

Certainly, tables *as currently implemented* have their faults. HTML itself has plenty of faults, while we're at it. Previous comments have pointed out that, with tables, you can't (as easily) move a navigation bar to the other side of the page. There are two answers to that, the first being that most serious sites do not make their Web designers type all that crud for each page, over and over again; instead, they use templates. The second answer is more of a question: Why doesn't HTML have templates built-in? I assume it will eventually, but it really should have had them from the beginning. Such a facility would have saved an enormous amount of bandwidth.

In the meantime, the W3C has (for some reason unknown to me) been more focused on giving designers a standardized way to fling dung at arbitrary coordinates on the page (a la CSS positioning), rather than on *reducing bloat*, which is clearly the more serious problem.

Jim Dabell 9:31 AM on 1 Nov 2003

Argh! It seems that everybody here has missed the point. CSS /doesn't/ mean avoiding grid layouts. CSS makes it /easy/ to do grid layouts. It's just that Microsoft never got around to implementing that part of the specification, and so we use floating elements and table elements as poor workarounds.

The very first comment here made that clear; I suggest everybody go and re-read that part of the specification, because it seems to have sailed right over your heads.

Stan Rogers 3:32 AM on 3 Nov 2003

Not quite. "display: table" (and table-row, and table-cell) encourages the same kind of containeritis that we in the semantic markup camp are trying to avoid, whether Microsoft supports it or not. There ought not be any markup in a document that does not directly correspond to the meaning of the document's content. That means no divs that do not, in fact, represent a logical division in the document, and no spans simply for their own sake. In order to use the table, table-row and table-cell display values, one needs to create artificial containers to act as the table and row in which a given cell lives. This is in no way better than simply using a table in the first place. Ned's suggestion does not require spurious markup, and is thus preferable in every consideration.

As for why tables for layout are bad, it shouldn't be a question any more. A table is a data structure. If the contents of the table are not, in fact, a table of data, then the tag is being misused. The fact that it was once the only way to achieve a reasonable design layout is no longer an excuse -- there are other ways available now that do not compromise the data contained on the page.

cmyers 8:32 AM on 2 Feb 2008

Here it is 4 years later and these observations are still relevant and the problem still endemic. As a desktop application developer who started working on all-HTML web applications about a year ago, I was appalled at the kind of unmaintainable trickery necessary to achieve the desired positioning without tables.

So it's 2008 and we're still using the same browsers with the same half-baked implementations of half-perfect CSS standards. To me, this is ever more indication that we should be using the tools we have available to us. No magical CSS specification is going to come swooping in to save us. Even if it did, I hope to be doing something different in my career in 10 years when it's finally supported.

We recently echoed these sentiments out of frustration. Oddly enough, we propose a layout element just like Doug Sauder's grid and give a meant-to-be-humorous python script to post-process your HTML.

Smeigel 4:13 PM on 18 Feb 2008

Well! this is fun stuff to read. I was charged with converting a HTML report to use grid formatting. I read every book I could find, and to my embarrassment, had a really hard time achieving this. There was no one at my site to help. Finally, another contractor with good experience was found and was able to achieve this. Of course, looking at the code, I can see in retrospect, how this is accomplished.
But, hey, I am so new to this, and encouraged at the above, not discouraged.

Smeigel 4:21 PM on 18 Feb 2008

Failed to mention that my hang-up was trying to use true row processing. Silly me.

Shaper 6:47 AM on 9 Jun 2008

> I understand why we want to separate content from layout.
...
> Why couldn't CSS have let me describe the grid of the page with familiar <table>-like constructs?

No, you really don't understand why we want to separate content from layout, or you'd realise that proposing extra markup tags (content) to control how the page is visually rendered (styled) is exactly the opposite of separating them.

Impossible CSS gripe #2

Comments

Add a comment: