Apparently there
remains some
confusion after my
Thursday-afternoon rumination on the potential use of tables, as opposed to pure CSS-based
layouts. I’m going to share some of my experience to help clear this up.

Some of the comments on this site were discouraging, it sounds like the
original piece was interpreted to advocate laziness. Some of the replies on other sites
perpetuated this interpretation, so once more, tables should be considered only with the
proper education to use them responsibly. This means
attention
to accessibility,
as well as offloading all other presentational attributes to the CSS, leaving the simplest
of layout-structural tables.

The point I was clear to make was that I am not talking about dropping CSS and going
back to 1997-era coding techniques. Standards-based coding practices aren’t so fragile that a
small injection of common sense and/or objective analysis will excuse full-scale dismissal, so
let’s not pretend like the world is going to use this discussion as a springboard to revert;
chances are the people who would are doing so anyway.

I am suggesting merely that in some cases, it might make sense to explore a
layout table. Again, I do not mean three-level-deep nested tables rife with the required
colspans. I mean a light table with two or three columns to keep a layout
together, sans all other presentational markup. This is what I have in mind:

The cellspacing remains simply because the CSS equivalent (margin:
0 applied to <td>s er, that is, border-spacing is what I was looking for here [thanks to those who clarified]) isn’t well supported. The
<tr> remains merely because it’s still required. The important piece of
this table is that three columns keep the layout together, as expected.

Why am I saying this might be preferable over floats or absolute positioning? First of
all, the pitfall of absolute positioning is that placing a footer below the three columns
is near impossible. Creating this layout using absolute positioning causes a reliance on
one of the columns to be longer than the others; given a dynamic site, if you build this
reliance in to your work you’ll get bitten by it sooner or later. Pages will start looking
funny when a column grows longer than intended, as the content area grows shorter.

Floats, then, are the more reliable way to achieve your three columns. Except that they
have their own glitches too. The most popular browser on earth, IE6, has spectacularly
inconvenient error-handling in this regard. Anyone who has built more than one or two
sites with floats knows what I’m talking about: a placed element too wide for its container,
be it an <img> or a <pre>-wrapped chunk of text, will
cause the parent element to grow to contain it. Other browsers let the content overflow to no
ill effect other than a bit of overlapping, but because the parent element resizes in IE,
the column gets bumped all the way below the others and you have a situation no one
is happy with.

I’m hearing contention against the claim that proper CSS design is hard. Okay, fair
enough, learning the basics isn’t terribly difficult. Learning the basics well so that you
know how to keep the above scenarios from happening is a different matter, and requires
browser-specific tricks that go against the nature of what CSS is meant for. Anyone can
build a fixed-pixel layout in CSS with known font sizes, that’s easy stuff. Build me a
liquid three column layout that allows for text scaling in Internet Explorer, and watch how
easy it is to break by increasing your font size. Especially once the code leaves your hands.
This is where it gets hard, folks.

Which brings me to my next point — working with other team members and clients. I
mentioned this on Thursday, but it bears repeating. There are many different working
conditions out there which don’t match your own. Assuming because you know how to
maintain your layout integrity with CSS that everyone else can is a leap of faith,
or the by-product of a cozy environment that doesn’t test your endurance.

I’ve worked in settings both where I’ve dictated all markup start to finish, and where
I’ve had to rely on others to continue producing valid, well-formed, structural markup.
The first scenario makes it dead simple to assure a site’s continued abstraction of
presentation, the second does not. Even if you have the most responsive team members, you’re
still limited to what they know. Like it or not, many people look at markup from a
presentational standpoint, ie. “this form element needs to sit below this label, insert
<br /> here.” Either you have to clean this up after them, or more likely,
you’ve moved on to other projects by this point and don’t have the time to.

A little bit of presentational markup isn’t going to hurt things, and probably, alone,
isn’t a justification for a structural table. What is is how likely the chances are
that anyone not-you is going to trigger something like the IE float problem mentioned
above. Anecdote: I built a site earlier this year that worked fine with my sample data. When
passed off to the client for implementation, breakage occured. The culprit turned out to be a
small piece of non-semantic markup that was used in various spots over years of accumulated
content. I was not contracted to clean up the content; the client had no desire
to fix years worth of material. The seemingly easiest fix was to throw the page into a
structural table. I knew a CSS hack or two to work around this, and we didn’t end up using
it after all; but would everyone?

Let’s also not forget that we’re talking amongst people who have spent a lot of time working with this stuff, and that there are those who haven’t. For a beginner transitioning to CSS-based design, a few iterations of table layouts that move more and more presentation to the CSS is one of the better ways to learn. Even once the intricacies of positioning are fully understood, it takes time to become comfortable with them. Let’s cut these folks some slack; their continued use of a table is just fine if they’re continuing their education so one day they don’t have to.

And finally, let’s talk semantics. I hate discussing semantics, personal interpretations
(unavoidably) shade the conversations. But let’s do it anyway. This is the point that’s
going to get me into the most trouble because everyone is going to have a different take,
but I’m going to throw it out there. Using a table for tabular data is
universally accepted as being proper use of a table. Which carries with it the assumption
that the table is structural and not presentational in that case. Fair enough.

But if tabular data is structurally tabular, then what inherently (besides a fear of the
past) makes a two- or three-column layout structurally non-tabular? Two columns
invariably end up in a pair of <div>s, or a pair of
<td>s. What makes the former structural, but the latter any less so? A
pair of <div>s implies two distinct, separated blocks of structure; a
pair of <td>s does the same, and carries with it the further implication
that the blocks are structurally side-by-side columns. Two columns may be presentational to
some, but they may be structural to others.

I’m not committed to the notion, but it’s something to think about. There are those who
would advocate multiple nested lists (scroll
down to Tantek’s technique) as a structural replacement for the <div>s we
use today, so if there are two ways to look at semantic representation of data, there are
just as easily three.

Anyway, at the risk of sparking a howl over the last point and ignoring what went before
it, I’ll finish by saying this is based on the sum of my experiences in real-world
situations. There are many factors at play here, and boiling this discussion down to
“tables bad, CSS good” is counter-productive at best.

I’ll end with the contentious quote of the day, coming from
Joe Clark:

If smart, informed
people are using b or i, it’s
because they have made smart, informed decisions to do so. We’re not slacking off; we’re not
making a mistake; we’re not harming the grand ideals of semantics or accessibility. We’re
not doing anything but using b or
i.

Different argument, misappropriated quote, but similar sentiment. Semantics only get you
so far; at some point, you have to compromise and just use the tools you have at your disposal.

Reader Comments

Great follow-up to a slightly confusing post. I’ve had many projects where I could have save myself time (and my client money) by simply using a layout table instead of trying to absolutely position divs all over the page.

I guess it boils down to “we’ve come a long way, but let’s not forget our roots.”

Dave, I’m pretty sure I didn’t misunderstand your original post, but after reading through the comments I got the feeling that some people did.
Anyway, after this follow-up I doubt anyone will still be confused :).

“Some of the comments on this site were discouraging, it sounds like the original piece was interpreted to advocate laziness.”

It was not. But it for sure will be taken by many as an excuse for going on “the old way”. Not ready for CSS in 2001, not ready in 2004… Story goes on.

Yes, the table you have in example is ok (except of cellspacing, I think border-collapse takes care of it), but I seriously doubt you will find many sites built using this minimal table. Either they will be pure css (some exceptions for really complicated cases), or messy nested tables.

No, I am not against tables for layout, but I am seriously confused when I see 30 or 40 or 100+ for the one page (and I am not making it up).

And I don’t think every web developer will switch to pure CSS layouts. It is not about how difficult or how easy CSS is. It is about how difficult or how easy is to separate structure and visual presentation in your mind. Put an before the word and it will be in italic - that’s easy. Inheritance, context and child selectors - that may be much more difficult to grasp. “You don’t style anything in your markup, and then you have it styled in some separate file? Weird!”.

I wish everything could be perfect. Browsers supporting the standards 100%, coders knowing the standards like they know their birthdates, and for gas prices to be under a buck fifteen. But we all know this will never happen. Just roll with it.

Don’t spend to much time trying to convert people. This pure CSS layout speach is starting to sound a little cult-like.

Thank you Dave. One of the reasons why I read your blog on a regular basis is because you are one of the few who advocate standards, and with quite a bit of thought…as opposed to many who don’t want to think about it, they’d rather “jump on the bandwagon”…

(edited the paragraph I was just going to write).

If most of the people commenting here are all about documents and only documents, then (for the most part) I will agree–try to avoid using tables for layout. If you’re developing in some other paradigm that happens to use HTML as the “rendering mechanism”, then in my mind all bets are off. Why? Because in general, you are aiming development at a particular platform.

Please bear in mind that the standards are there so that we, as developers, can write once and deploy everywhere. Also bear in mind the disconnect in the implementation of those standards, and account for them as well. I personally am not going to take the time (unless its part of the scope of what I’m developing) to figure out a way of using CSS to accomplish–completely–what I can do with a table.

I also wish that some of those who advocate pure CSS for the sake of advocating pure CSS would realize sometimes that the client is not the only place things can be written or adjusted. I think its perfectly reasonable to be able to create a semantic document store, and alter it (a la the last comment, or via some other means) for presentational purposes on a particular client. The really nice thing about this solution is that you can serve in a number of different formats (including the pure semantic version) if you so desire.

To summarize–don’t stop advocating, but understand that we are still in the early stages (believe it or not) with web tech, and haven’t gotten to the same point that, say, tools or home items have gotten to.

And I certainly will never feel bad when I use a table within an HTML document.

(now, if I used a font tag…then I’d invite all y’all to come and shoot me ;)

I agree with your suggestion that TDs in some cases are no less semantic than DIVs. To expand on two of those points:

1. The main argument I always hear against tables is that “they were originally intended for tabular data – not to position columns.” Well floats were never intended to position columns either. They were intended to shove items like pictures and pullquotes off to the side and have paragraphs flow around them (kind of like the old school align=left you’d always give to inline images in the middle of paragraphs). So if people are going to question the original intent of a table, *they must apply the same scrutiny to floats*.

Absolute positioning, however, was intended to do exactly what we are talking about: separating layouts into discrete areas of screen real estate. Most people find absolutes much easier to deal with, and much less susceptible to the fragility that floats suffer from. Also, they free up your source order tremendously. With floats, you always have to worry about which div comes before which in the code.

A few days ago, I suggested on Andy Budd’s site that if the *ONE* Achilles heel of absolute positioning could be solved, everyone would use it. That is, as you mentioned, absolutes get taken completely out of the document flow and thus cannot be “cleared” as a group, as is most evident in the example of placing a footer. Well, no sooner did I make that suggestion did Shaun Inman, one of my idols of late, solve that problem beautifully, albeit it with javascript: http://www.shauninman.com/mentary/past/clear_positioned_elements.php . Now, neither Shaun nor myself are saying that a javascript solution is 100% the way to go, but it does point out one important thing:

Browsers *can* calculate how to clear absolute divs, so if the CSS spec was written without this critical feature missing, we’d all be using absolute positioning all the time.

2. To carry your TD example further, take the example of a two column blog. The main column is your main entries. The side column is your peripheral information like links, blogrolls, archives, etc. How is this any different, semantically, from a two-column table where the left side is, let’s say “Reasons the Mariners will win” and the right side is “Reasons the Yankees will win”? You’d certainly consider the latter tabular data, so why not the former?

I think where it starts to get non-semantic is when you use tables to split images into grids, like with a row of vertical navigation buttons done as images. That, can certainly be considered using a table beyond its intended use, but splitting up a couple of columns doesn’t necessarily qualify as the same crime.

I share the feeling, why be a massochist when there is a clear structure to present tabular data and that is … roffel… roffel… yes a table.
While it is silly to use tables as main presentation tool for all sorts web widgets because of the double pass.
It is just a tool like any other tag used in xml and as long as you use it to carry tabular data and do not nest it within other tables, use other markup means like span (inline) and div (block) to manipulate the inside of a cell.
anyway, choose a table when the workaround in pure css with divs are not worth time and headaches and when unlucky processor power, that is all rows with more than 4 columns anyway.

Re: cellspacing. The margin property is not actually intended to be used for spacing table cells. That’s why it’s not supported in that capacity by most/all browsers.

The correct property for this is border-spacing, which last I checked was supported by Mozilla but not Win/IE (haven’t checked any others). However, whether or not *any* border-spacing (or the cellspacing attribute) is used is determined by border-collapse: collapse/separate; and this is supported by every browser I’ve tried it on.

So, to get your cellspacing: 0 tables without a single HTML attribute involved, in almost all CSS-capable browsers, simply apply border-collapse: collapse to the table element.

As a novice CSS user I think CSS is beta code at best. If it was a programming language you wouldn’t even consider it for production code.
Having said that I am using CSS because it is fast and efficient. But I get frustrated when really hacky CSS or utter perversions of existing semantics get propagated purely in the name of not using tables. Take the Numbered List Pairs discussion over at Simple Bits as a case in point. To my mind that just makes the whole CSS movement look bad.
The whole flexible grid layout metaphor is very powerfull. Unfortunately neither tables nor CSS map to it particularly well. If anything tables are the better fit.
And please. please, keep your absolute positioning away from my browser. To my mind the introduction of absolute dimensions to HTML/XHTML/CSS was one of the biggest retrograde steps in the history of the browser. In my occupation I am dealing with documents on the web more than pretty visuals and documents inevitably get written in MS Word. Because absolute sizes are available MS Word uses them and the result is abyssmal and totally contrary to the spirit of html.

I agree that tables are still required in certain real world situations, and I don’t mean to undermine that essential point. But trying to find a semantic justification for this is troublesome. The reason tables are still required is, as you say, the varying implementations of CSS in browser technologies which lead to inconsistencies of display. Not because they are an alternative way to structure block data semantically–they really are for tabular data.

If everyone were to use tables for tabular data, the tighter semantic meaning of the element (“this is tabular data”) will enable software to do more with it. What has generally filtered down as “tables bad, divs good” was originally not a subjective edict: it derives from the fact that tables have a very precise semantic meaning, and divs have just about the loosest possible semantic meaning (“a block of data”). Divs are actually bad semantically, because to software trying to interpret the meaning of their contents, they explain virtually nothing. It is a good idea to find something more meaningful, but of course XHTML is quite limited in its options. It’s still better to use a div from a semantic perspective than a table unless your data really is tabular, because you aren’t diluting the semantic meaning of the element for everyone else–it actually can’t be watered down much further, whereas tables can. (Incidentally, tabular data is hardly a mythological beast; there’s a lot of it about, and there are plenty of occasions where tables are therefore the best semantic option.)

It’s important not to see tables as exceptional in this regard; this is a concern that afflicts any element with a comparatively precise meaning semantically–including lists. There’s a pretty simple rule of thumb for avoiding semantic dilution: “Is this really a list? Is this really a table? Is this really a definition? Or is this really just a block of content not adequately described by any current XHTML elements?”

That said, semantic purity is a long way off, and the practical benefits of anything like it are a fair way off too. Use tables if you have to, but I don’t think it’s a good idea to come up with semantic justifications that merely muddy the waters.

Absolute positioning refers to a specific property that is not actually absolute at all… it’s relative to its containing block. So, I could make a left column that is 33% the width of the screen and make a right column which takes up that remain 67%, and that would be achieved with absolute positioning.

A few other things to note: Mike D, floats are presentational properties, not structural elements. They’re in the stylesheet, not the xhtml, so they have zero semantic value. They’re not even examined, so you can do the most preposterous things you like with them, and it is still 100% valid, and positively good. It’s important not to confuse this.

Steveg, CSS is not beta, alpha or final code–there is no code. CSS is a specification, with many implementations in various browser technologies. Some of these implementations could be called “beta”, if it makes you feel better. :)

Your point is a good one. Floats are not part of the structure of the document and thus they are not unkosher from a semantic standpoint. I do, however, feel less disappoint about their shortcomings as they relate to multi-column layouts than I do about the shortcomings of absolutes. Blaming floats for messing up your column layouts is like blaming your car for not flying. Using floats to create multi-column layouts still goes against what the W3C seems to have intended them for, whereas absolutes were made precisely for this.

The original intent might not necessarily even matter to people, but what matters to me is that absolutes were created specifically for this purpose and they come up short in one tiny but important way. A way which could have been avoided if someone just brought it up at spec time. A way which browsers themselves can see their way around, if injected with the right scripting.

Well said - I don’t know what was what confused so many on your previous post. Over the years, We’ve taken our chances on client’s sites implementing the best of our CSS knowledge and though we already have a bunch of great, functional, tableless sites under our arm, it is also true that they are a major pain to build, implement, and be way more time-consuming (in testing across browsers) than if we used a barebones table layout to hold all things together (We do it depending on the client’s needs)

Note that I said “barebones table” not “a bunch of nested tables”. Of course, we use tables when it comes to show tabular data (duh!) as well.

Bottom line: Being a web standards advocate and supporter is a lofty goal and must be an important commitment, but it is even more important to have a life. You know what I mean.

Joseph: I understand that. My bad for missing the “like” that I was thinking. However the specification is still beta quality. I would much prefer that they cleaned it up and issued a validation suite before they moved on to CSS2 and CSS3.

I ran accross yet another quirk yesterday. In Galeon two divs with backgrounds one after the other. The backgrounds don’t meet even with 0 width borders, margins, and padding. But, add a 1px border and they magically join up. Why? This is worse than the C compiler incompatabilities of the 80’s and there is no way to look at the “generated code” (none generated) to see what assumpions are being made.

Yet … seperation of presentation and content is such a necessary thing to do. I just wish divs had an @import syntax so that I could split and reuse content as well. I just wish enough worked that I didn’t have to spend time debugging what should be really basic layouts.

Quite daring, to curse in front of your own church assembly. ;-) I can understand where you’re going, though: if technically carried out well, the only thing separating tables-for-presentation and ‘semantically correct’ div layouts is personal conviction.

In one respect, there seems to be no signifigant difference between table cells or divs if used for presentational purposes. Both are redundant elements, added to information to provide hinges for your presentation. (Let’s be frank: divs serve exactly the same purpose as tds, in this respect.)

There is one flipside, however, that’s important: with tables, you imply a semantic link between the content ‘blocks’. With divs, you do not. Three divs after eachother, or even nested, do not carry an intrinsic meaning.

Quite interesting: I’ve never seen headers for presentational tables. Would be daft, but correct: [th]navigation[/th] [th]main column[/th] [th]side column[/th]. You can always use your text-indent: -9999px; to hide the headers, ofcourse. ;-)

There is a difference between people who think logically and fanatics. The fanatic tends to get fired after he failed his 3rd deadline.

Quote: “Just.. use.. tables.. please? We need it done yesterday.”

Quote: “You’ve been busy with that XSL template for 3 days now. Done yet? Oh you have been checking it on W3c a lot.. nice.. is it done?”

Quote: “Oh wow it works on a browser 0.0003% of the world is using. Great for your ego. Say, we just got a call from that customer, he’s wondering why the middle column overlaps the bottom of the site when he enters too much text.”

Quote: “Hey we’re going home and taking tomorrow off, too. I asume you continue working tonight, tomorrow, and in the weekend? Yes? Great! Maybe we will finish this deadline this week.”

Quote: “So you worked thursday evening, friday when we were having a day off, saturday AND sunday, and you are STILL busy implementing ‘hacks’ to your CSS?”

Quote: “A hack you say? Nice. What happens when this ‘bug’ is fixed with IE7? We will have to change it? I see… remove it.”

Tables were used to do the layout from the middle ages, because it was the safest way to do it. IExplorer hasn’t changed since, so why should we abandon these practices? We have CSS, but until IE doesn’t evolve, we cannot rely entirely on it.

I think the whole ‘it needs to render correctly in IE’ is overrated. With only a few hacks/tweaks, it’s possible to achieve nearly the same results in IE6 or MOSe.

The whole, ‘We need to support NN4’ should be bannished. If you can run NN4, you can run FireFox or some other lightweigt standards compatible browser.

I believe CSS compliance will be on IE-devs’ short list, not in a small part due to the overwhelming amount of comments on the Scoble blog, including comments from some of our ‘mentors’. Then again, the whole XaML thing could be a threat to the very fabric of the www.

amen. i feel vindicated.
for all my kowtowing and beating-head-on-keyboard in my efforts to learn and use CSS, i still use a 3 column table as a base, and build everything inside it (with little other markup, as you suggest).

it’s a comfortable way for me to learn CSS without the angst of floats and positioning. however it also makes me feel guilty and inadequate because i’m not doing it “properly”.

I am all up into this topic. As a new comer to the css design blog scene it is funny how sometimes we can’t see the trees from the woods, so to speak.

I think it is good that as a community there is a strong direction for coding well, but sometimes I feel that we become slaves of semantics or what-not. I am sure there are many people who have had a similar experience coding something that really, really should be in a table second guessing themselves as to whether it should be.

Those quotes that were posted were interesting, and suprising coming from me, I found them to be pretty true. Doesn’t happen all the time, but for me, I can’t afford to spend extra time a client DOESN’T have just to worry about getting a CSS layout to work. When a client is paying $15,000 for a website and their site launch is on the 15th, well, that site better be launched on the 15th. Too be honest, I have strayed from building a PURE CSS layout for my companies clients because of the inconsistincies I am worried about happening when they view their site. Many of our clients still use old browsers where the css support is iffy. So my solution is to do a hybrid layout (Tables + CSS).

My recipe is just a nice light table (1 at the most) stripped of all the flavor (no borders, margins, padding, etc…). Then it is sprinkled with a nice linked stylesheet to give it the BAM that it needs. Sometimes, you just have to use what will work and what falls under the clients timeline. Its their money, and the more hours you bill, the more money you spend of theirs, and the more money THEY spend, the less happy they are.

Hemebond - you *definately* have a point there! I did not see anyone giving much reaction to that, disappointingly.

I tried to arrange something with table CSS display properties a while ago… It yielded somewhat strange results but that might be due to misuse of the margin property or something, and lack of support in browsers. It was only a quick try and I didn’t put much time in it, so I didn’t research it thoroughly.

Afterwards, I only sporadically read something about it (this note in this discussion is only about the 3rd time I see it mentioned), but my general impression is that the main reason for not using those properties is that they are not very well supported. But, note that this is *not* due to actual experiences! It is really just what I gather from some rumours here and there. I think I will look into it in more extent soon.

The nice thing though with table display properties in CSS is that you don’t need to have the whole table structured! CSS will basically ‘make up’ every table layer you forgot. You can create tables without TR tags, or even one without TABLE tags (and this might be the thing that IE doesn’t support well, at least I could imagine it to be). So usually it probably won’t require additional markup… Sounds very powerful to me…

I don’t think I’ve seen it in the comments since the suggestions to use border-collapse, so I apologize if I’m repeating.

Mac IE 5 does not handle the border-collapse technique to replicate cellspacing=”0”. Most other recent browsers I’ve tested do. When I use tables, I go ahead and plug in the border-collapse in the CSS, but also add cellspacing=”0” for Mac IE 5.

Someday, once that dead-end (per Microsoft) browser falls to fractional share, I can go back and take out cellspacing=”0”. ‘Course I’ll probably redesign any pages that carry it at least once more by then anyway. :-)

Hemebond: it’s a great idea, except– sing it with me, now– applying table-related ‘display’ values to non-table elements doesn’t work in IE/Win. So that’s another promising idea shot to heck by practical considerations, I’m afraid.

Dave: as others have pointed out, but I’ll reiterate, ‘margin’ does not apply to the internal elements of tables. CSS2.1:17.5, found at http://www.w3.org/TR/CSS21/tables.html#q7 , says this explicitly (it’s the third sentence of the section).

Funny how not entirely new a concept discussed on a personal blog can be quickly misinterpreted and spread around the world in a totally different guise. I guess now you know how much weight your words carry. Maybe you are the John Lennon of Web Standards, or something lol :)

Wholeheartdedly agree that table structure is a useful alternative to wrestling with floats for a 3 column layout. I’m still pretty much terrified of them.

Hemebond: I worked up a test document (http://crossroads.net/misc/tabletest.html) using table layout on non-table elements. Works like a charm, except in IE.

>>what inherently (besides a fear of the past) makes a two- or three-column layout structurally non-tabular?<<

OK, I’ll bite. DIVs and SPANs have no structural or semantic value (some people point out that the I tag is semantically dead, and for some reason prefer convoluted SPAN constructions–I never understood that). When you wrap one of those tags around a chunk of text, you’re really not adding any information that a mythical structure-sensitive UA should try to extract. When you wrap something in table tags, you are. If it is reasonable to consider rearranging the contents of the DIVs/TDs, hiding some of them for the print version, or treating them differently in a spoken/braille/lynx edition, then it’s presentational markup–it’s not a table in structural terms, and the side-by-side appearance has visual value only. Visual != structural. I can imagine this mythical UA responding to requests like “read me all the cells in row A. Ok, now in column B. Now sort-increasing based on column C. Now sum up rows 1-4 of column D” This would be nonsensical in a layout table.

I respect the argument that tables can be used for pragmatic reasons, but I wouldn’t try to justify it by saying there’s some nebulous, inherently tabular quality to the layout when you do that.

Funny how you started with a personal blog Dave, and now you have so much pull on the net. It would be interesting to see if you would write an artical on how the use of ‘tables is a must’ and switch your home page to tables, how many web developers all over the world would lose sleep.

I think at this point in the game we are in transition and table sites are still acceptable. But soon clients will start saying: ‘Why is my competitors site viewable on my pda and not mine’. The internet is growing so fast that in my experience if you miss the boat it just gets more difficult to jump back on.

I think it’s good to push but if someone doesn’t want to be pushed, let them be, there’s too many people on the boat anyways. :)

After all it’s not that difficult, table = tabular data.
And if you remember html was difficult at first and it’s still a pain to validate.

“I think most people would agree that CSS development has a much higher barrier to entry than table based design. In an odd way, I think this is one reason why CSS based design is becoming so ‘popular’ amongst web professionals. It allows them to differentiate themselves from the amateur ‘FrontPage Cowboys’ and take back the web for themselves. Perhaps this is why many people see web standards as ‘Ivory Tower’ and why many web standards advocates come across as having a sense of superiority and a zealous attitude towards web design.”

A couple years ago, I heard tabular data described as data that still makes sense when its rows are made columns and columns made rows. I don’t remember the source for this idea, probably a member or link from the css-discuss list. I wish I did, because it made a lot of sense to me and has guided how I think semantically about tables and use them in marking up content.

As a special case, the data in a table with a single row and multiple cells will read the same whether read row by row or column by column. The same is true for a table of a single column. So as long as an author is OK with having an immutable order dictated for his/her content, a single row/column table should be semantically OK for marking up a series of data points / cells / sections.

This perspective is attractive to me because it’s an argument based on semantics for the light use of tables in marking up “non-tabular data”. I can appreciate the “just gotta get the job done” approach, but I rest just a bit easier when I have a justification based on semantic reasoning.

There are good reasons and bad reasons to choose tables over divs for a layout. One of the bad reasons is because one is lazy. A good reason is to save time and make the money and sparying your client the pain a new webmaster could cause.

a) it is hard to design a pure css compliant site that works for all browsers on all platforms.

b) sometimes one has to use tables to make the deadline and to make it easy for the cleint to update/maintain their site.

and all this because there is not one standard at the browser level.

and why has no-one has developed a markup-tool that is css savy, that uses a wysiwyg interface that validates, and that is proofed to work on all browsers. i.e. a pagemaker-like tool for web-layout that can export to a pdf like standard; in this case PURE CSS.

once we have this tool then life will be easier.

in the meantime throw some css on the table, and fill your glass with some good vino and smell the roses.

Although I don’t think it’s a crime to use table for presentation, there is two good reason why I’m still trying to build website with only CSS.

1 - Printing a table base design even with a print CSS is somewhat of a hit or miss.

2 - CSS are simply more flexible.

I still think it’s pretty easy to build a pure CSS site even for Explorer 5. It’s not for every design and it can go pretty wrong but it’s possible and when you’ve been going it a while you don’t really see the difference between table and CSS positioning. I actually had more bugs and weird behaviour in the mixed table/css design that I’ve just completed than in straight CSS positioning.

Your article starts out by discussing the practical side of www authoring. It’s reasonable to argue that a simple table layout is easier to implement than css. Although you don’t explain why, I can imagine my own reasons. For the layperson – and most webmasters are laypeople in terms of www technologies – tables are easy to understand because they give the author a grid with which to lay out the page. More importantly, they provide web authoring software an easier means of offering a wysiwyg mode to users.

What noone seems to have mentioned here is the lack of support for css tables. That would have allowed for semantic html with separation of content and layout, and still provided the ability to use a program to drag boxes around the screen. Pity MSIE/Win does not support css tablelike presentation, then.

After writing quite a bit about practical issues, you then veer off course with this nonsense:

[quote]
if tabular data is structurally tabular, then what inherently…makes a two- or three-column layout structurally non-tabular? Two columns invariably end up in a pair of <div>s, or a pair of <td>s. What makes the former structural, but the latter any less so?
[/quote]

It’s hard to imagine how anyone writing seriously about markup could get so confused. Using two <td> elements in the same <tr> says that the content of the <td> elements has some data relationship. Using css to place two <div> elements side by side does not.

Consider a catalog with product name in one column, catalog number in another, and price in a third. Those aren’t in <td> elements because they look nice that way. They are logically connected, and must be presented to users for them to make any sense of the data.

It may be true that css is too hard, especially for novices, but no amount mental gymnastics will convince me that tables were meant for layout, any more than blockquote was made for indenting text. The only reason noone argues for the return of misusing blockquote for layout is that indenting text with css is easy. By contrast, replacing table layout with css floats/positioning is hard.

I couldn’t agree more with your previous post.
I learned web design via notepad & tables (3column, box layouts) till just recently I discovered something they call CSS-P ;) Now before this point I had only known css as an inline stylesheet for creating textual formating for html documents. Currently i live by compliant xhtml/css “separate content from style”, w3c.org and upgraded to homesite+ ;) tried wysiwyg dreamweaver but felt more productive hand coding. I find CSS very versitile for layouts. And tables are good only when needed.
I found your site through ala and it had a good vibe so i visit often. Great content, keep up the good work.

“Then again, the whole XaML thing could be a threat to the very fabric of the www.”

Bullshit. It could, but it won’t be. PDF *could* be a threat to text files / HTML docs, AppleScript *could* be a threat to JavaScript. There’s not a strong enough momentum in it for replacing HTML even for the developers; for them, it’s just a good new way of writing forms.

Yes, I’m fully aware it can be used to create PDF-ish documents and that it’s (reportedly) being used to create new developer documentation. So’s POD for Perl documentation, and JavaDoc for Java documentation, by the way; I don’t see any takeover claims here. No, it won’t replace 12 years and thousands of GBs of prior art.

I agree that in some cases it makes more sense to use a table than it does pure CSS. 99% of those cases are an attempt to foil CSS browser bugs, especially IE.

But I think you’ve done us all a disservice here, Dave. I think we all use tables now and again in places we shouldn’t. It’s our dirty little secret. But now that you’ve brought that out in the open and basically given it a blessing, those who don’t understand CSS can use it as a license to keep on writing bad markup.

I received an email today from a co-worker who still thinks FrontPage is a good idea. He suggested that “See – it IS ok to use tables,” and pointed to your article as evidence. Of course he didn’t read the whole thing. In fact he probably didn’t read any of it, the title probably came through on his newsreader. But that was all the evidence he needed to know that CSS wasn’t necessary.

Well, are there any good tutorials telling me how to make a good ‘complex’ layout through CSS? I’ve been using CSS for a long time, but I’ve mainly been using tables for my layouts.

Then I thought, if there’s a way I can get a simple change to appear on every page, it’s through a CSS layout!!

But all I’ve found in tutorial form is the simple 2/3/4 column layout. I’m designing something more complex: a navigation column, and a main content column, within which is a further column for highlights.

Thanks for defending those of us who may be a little behind the CSS-wagon. I’ve been frantically trying to become an expert for the last few days, hoping for my latest dynamic web site assignment to be functionally, structurally, and syntactically immaculate. Needless to say, I’ve become a bit frustrated.

I was debating whether making SOME changes in the already finished portions of the site(but not enough to validate or meet recommendations) would be worth my time. Your post reminds me that this won’t be my last project. Most importantly, each will be closer than the last to that goal of immaculate design.

Thanks for your support!

Kayt

Search this site:

About This Entry:

You are reading “Tables? Oh, the horror!”, an entry posted on 15 May, 2004, to the Arc Flag collection. See other posts in this collection.