Here’s a code sample from someone who obviously misunderstands the fact that “it’s okay to use tables for tabular data”, and probably spent more time than was necessary coming up with the CSS to make this work:

A misguided waste of time, for sure. You’d think the class name “pseudotable” should have tipped me off that maybe I was going about it the wrong way… and I coded this only last month, too. Here’s the much more sane data table I ended up with:

Update: as a few commenters have rightly pointed out, there’s more that can and should be done with a data table like this one. You could go as far as something like the following if you’re so inclined:

Yeah, it’s definitely right to use a table when appropriate. And it’s always important to be on the lookout for unforeseen advantages to a particular approach.

For example (sorry to css-d folks who’ve already seen this), even though a calendar is best done with a table, when you use a list, you get a neat rollover property for free: http://uwmike.com/layout/calendar/ie5.php

Not to slight Mike Purvis, but I did manage to take his example and translate it over to a table-based layout for the calendar and still have the mouseover divs show as they did for the ordered-list.http://www.webcudgel.com/misc/calendar/table.htm

Naturally, it’s not AS clean as using the list, but it still works in very much the same manner as the example (a rewrite on the javascript used by IE was required to properly access the TD elements).

Charles Martin: The advantage of the list (with the rollovers) is that on a non-css agent, it unravels into a clean agenda. Whereas the table has huge blobs of text in the cells, so it would be unusable on a phone… Also, the list-based calendar would lend itself better to a style-switcher for different formats, if you’re into that.

But yeah, the table<->css issue is not always as clear-cut as it looks.

I did the exact same thing a year or so back. I was using a PHPNuke CMS and building my own CSS-layout theme for it. I was very much in the “tables are the devil” mindset that you describe and while I was very pleased with having torn apart PHPNuke’s default table layout, half a dozen pages listing tabular summaries were suddenly in lists…

Worse still, each “column” in my list had a blatent separator (paranthesese, square brakets, a hypen or two, maybe a colon). About a week or two later I looked at it, saw how silly it was and went to much effort to swap it back.

I think this is the kind of lesson that comes to all of us who live standards. Maybe it’s important to vary the kinds of bleeding edge techniques we use (tableless layout was once that, of course). I’m convinced that spending so much time working only to destroy <table/>s gave me some kind of CSS tunnel vision.

This same kind of “whoops, too far” could so easily happen with the newly beloved ‘creative license’ we have for definition lists too. I’ve sat with a colleague at work working out the XHTML structure for his Blog’s sidebar and we’ve watched the slow trainwreck of slowly but surely transforming the entire navigation structure into a nest of <dl/>s. We paused for a moment to survey the wreckage.
“Nah”, we said.

Mike, very good point. I very rarely consider a non-CSS view of the page and it does degrade quite nicely. Hrm… now I’m considering this format more than the table just for that reason. I just wanted to see if there was some specific advantage visually and functionally between them. Not really, but your version is much better from a style-less perspective. Much to learn, much to learn.

Hmm, that information looks more like a definition list? - with more information such as “date” in the definition title, which could be hidden in the CSS. However, this adds a lot more unrequired content. But, surely if it’s tabular data it should have table headers? That span the columns?

Am I the only one who can never get table styles to look the same in every browser? I usually prefer to lay tabular data out with spans and CSS in spite of the extra styles required. At least I’m in control that way, instead of the mysterious workings of <td> borders and spacing.

I still see nothing wrong with tables, even for normal page layouts, etc. Of course, I see that all that slicing in Imageready and stuff cannot be made worse, but normal “header, content, sidebar, footer” cells don’t hurt at all.

Nice!
Although the structure still looks a little bare for a data table.

Your little problem reminded me of a web app that my company payed for. The programmers who developed it utilized about 200 different stylesheets and didn’t use one table for any data. My buddy is pulling his hair trying to even attempt adjustments to it. I feel for him, he got handed crap.

You know after reading 3 books on Accessibility, I think the misunderstanding out there is that you can’t use tables at all, no matter if it’s for data or layout.

This simply isn’t true. Sure pure CSS layouts help to alieviate some of the “Functional and Situational Limitations” addressed in Accessibility and help bring a finer separation to presentation and structure, but it is also not the end all answer. Tables are still ok, as long as they are done CORRECTLY, making sure Layout tables linearize correctly for semantics and document understandability or that Data tables are marked up correctly so that data still makes sense and is associated with the correct headers when read or displayed linearly. But in the end of course it truly depends on who your target audience is and on what types of devices you want them to be able to access your site on. This is where pure CSS layouts have an advantage/but still some disadvantage.

Of course that leads to another problem, Usability. Sure you can design 1 site to be viewable on a 21 inch monitor as well as a 5 inch PDA, but is it usable? Most likely not, all that data and info being squeezed into a smaller, less viewable screen is sure to bring about many usability and accessibility problems (refer back to “Situational Limitations”).

I like this post. It’s time for the CSS zealotry to ease up, for the web standards folks to take a collective deep breath, and for everyone to consider what the right code for the job is rather than what the “fashionable” approach is.

I guess the ‘web-standards-drive’ shouldn’t have used the phrase “table-less” but something like “inline-style-less” or “minimal-styling”. As you also have people putting all their style inline - all the time - and then proclame with a straight face that they “get” webstandards. Oh well.

After having done the entire CSS for the Symphony UI, I’ve learnt a thing or two about tables and CSS (doing them the semantic/accessible thead, tfoot, tbody way of course). You might find it helpful to know that you can get rid of that ugly cellspacing attribute and instead use:

table { border-collapse: collapse; }

Keep the markup free from stylistic information, since that’s our whole purpose with using CSS right?

Tables as well as lists are presentational elements. Yes, I am serious about this. But what drives my sick and twisted mind to such a statement?

Well, itÂ´s pretty easy. When you think of a list, you always imagine one column with an arbitrary amount of rows. Of course you can use CSS to position every item differently and way out of context but in the end, a list is a bunch of rows. Nothing more, nothing less.

What about tables? If you take a look at them, they are nothing else but a bunch of side-by-side lists. You could also say they are two-dimensional lists because the semantics apply to both axis, although the meaning is different for each case.

Now what if we had an element called “set”? Or “enum”? Or “collection”? All of those have no dimensional limitation implied nor are they strictly associated to a specific presentation. Every set or enum or collection could contain an arbitrary amount of subsets or sub-enums or sub-collections.

Now you might ask: But what about the semantics? Well, you donÂ´t gain any but you donÂ´t lose any either. A table row is a row and no machine is able to tell you what the data actually means. Same applies for table headers or footers. A parser will know which head and foot belong to which column, but they still cannot tell anything about the actual meaning. So be free to add a header to a set or maybe a set description and you have the same possibilities without the separation into different elements. If you still arenÂ´t convinced, ask yourself following question: Why donÂ´t I simply define a one-column-table instead of a list?

So what am I trying to say anyway? DonÂ´t use list and tables? But what to use instead of?

Well, nothing. Keep it as it is. Why? Because there is no alternative. The whole point is to explain why I think that there is a huge gap and misconseption in (X)HTML about sets and collections as well as the public understanding of presentation. Further, I have no idea how one could present a four-dimensional set and above, but this still doesn’t mean I cannot define one. Just think about arrays in programing languages.

For a while I searched for a way to present forms without tables, lining up labels and inputs with all kinds of floats and spans. Then I had a Dave “what the heck am I doing” moment, kicked my own butt, and went back to using 2 column tables for forms.

Since then I’ve lost 35 pounds, my salary doubled to 700k per annum and and beautiful women throw themselves at me constantly.

See, tables aren’t so bad in the right context. I have to go now, I’m in the middle of a bike race.

To all those people above saying things like “I usually prefer to lay tabular data out with spans and CSS”: TABLES ARE FOR TABULAR DATA. That’s why it’s called tabular! Semantics, accessibility, etc, etc.

And I’m sure you meant to close those <th> elements in your example with </th> and not </td>.

- summary attribute on table
- a thead tag with a row of th’s (you can hide this from visual browsers if you need to by moving it off the screen with CSS, so screen readers can still read it out)
- stick some scope’s in the th’s of scope=”col” and for those events, make that first td have a scope of row.

That way your table will be semantically more useful. I think jaws will soon be supporting some of this. Even if it doesn’t, it is all about future compatibility, right?

If you and other prominent people don’t do it, no one will, and screen readers won’t support it…!

Curious Dave, what exactly made you think that a list was the solution initially? Was it just that you didn’t ‘think’ at the time or was there actually a ‘reason’ why you walked the list path instead of the table one?

Re Tom’s
“For a while I searched for a way to present forms without tables, lining up labels and inputs with all kinds of floats and spans. Then I had a Dave “what the heck am I doing” moment, kicked my own butt, and went back to using 2 column tables for forms.”

Forms are not tabular data, thus should not be written as tables. Very nice, functional, valid forms can be designed with simple, straightforward CSS. Example: http://www.alistapart.com/articles/practicalcss/ (scroll down to “FORM(s) and Function”).

One day CSS will have typographic grids, so that we can again have layouts up to the creative standards we had with tables.

I’m not saying tables were a good thing for layout, but the grid structure they provided *was*. I’ve read so many hacks and workarounds to get CSS and semantic markup to produce layouts that would be simple if an underlying grid was available. Setting guidelines and grid-points in a stylesheet would be straightforward and should help free us from the hell of float-itis.

Hundreds of lines of data, [time, date, duration, cost etc for each call] all of it tabular, all of it assembled to look like a table with CSS [divs, spans and the weirdest class names]. Unreadable if you changed the font size even slightly.

One other thing I want to throw into this debate is the situation where you want an entire row of a table to be clickable. This can be accomplished with a splash of Javascript, of course, but sometimes a list can be an elegant solution.

The issue becomes even more muddled when you start dealing with a table that has only two columns, since that’s starting into definition-list territory. I have an example that I started out doing with a table, and then ultimately switched to a list, for the sake of row-highlight and row-clickability.

Search this site:

About This Entry:

You are reading “Too Far”, an entry posted on 31 March, 2005, to the Rusted Staples collection. See other posts in this collection.