Standards with sanity

A lot has been made out of the importance of staying within web standards and making sure that your code is semantically correct. The biggest thing that so-called experts talk about is the avoidance of using tables. Really, they mean not to use tables for layout. The argument is that the markup should be able to persist no matter the set of styles applied to it, and that the content should make sense to screen readers as well as traditional web browsers. But there is such a thing as going too far.

I’ve been in situations where, with deadlines looming, I’ve spent way too much time trying to create semantically correct markup for visual designs. The question is this: does it make sense to spend four or five days fighting through CSS inconsistencies across browsers to achieve a layout that could easily be accomplished using tables in less than a day? I know some people who argue that it’s worth spending those four or five days to make sure that semantics are all correct because it’s the “best way”. But what makes it the best?

I am all for accessibility and making sure that your content is available via screen reading software, but there does come a point where you need to question the amount of work necessary to make things purely semantic in the business world. Will your product manager accept “it’s not semantically correct” as an excuse for why your deadline was missed?

Now, I’m not saying go out and start using tables everywhere again. I agree that, generally speaking, tables shouldn’t be used as layout. I think that there are enough examples of how to layout pages in any number of columns, with and without headers and footers. But for specific sections of a page, if you find yourself fighting with a CSS layout for a couple of days that could easily be accomplished with tables, ask yourself what delivers the most value for your company.


  1. Richard York

    I don't think tables are so bad for layout, if you're not going overboard with it, which is a bit of a retraction from previous opinions that I've held on the topic. I just don't think it's the /best/ way, because it's not the most /flexible/ way. There are more pedantic people out there that won't concede the use of tables for anything layout-related. And even more pedantic people, dare I call them clueless, who won't use tables for anything, even their semantically-acceptable uses for showing the relationship between data sets.

    I still use tables, for example, to layout input forms. I don't see a better or more semantic way of doing that, personally. I don't want to use definition lists, or any other kind of list for that matter, or hacks with the <br> tag, or any of that other nonsense, it's too much work to accomplish what's easily done with tables. And I would argue even laying out a form with tables is a semantically-correct use of tables. You are essentially showing a relationship between label and input, and the other bits that make up an input form.

    That said, it doesn't take me five days to do a table-less layout. It might take a couple of minutes to a couple of hours, depending on the complexity of the layout. CSS beginners struggle with browser inconsistencies and hacks, but once you gain experience those things become second nature. Your instincts sharpen and you begin to get a feel for what will trigger this IE bug or that IE bug, or what to do to fix this or that bug. I say IE bug, because 99% of the time, that's the browser that I have to do hacks for.

    To get to that level it takes a thick skin, and a willingness to experiment with the browser. I've been in situations several times, where I just start throwing anything at the browser till I get it to work. It's a mountain to climb up, but it becomes a molehill once you've already climbed it.

  2. Emilio

    I agree completely with you... maybe the correct way is to develop new generation screen-readers intelligent enough to discard layout tables when parsing a page...

  3. Lonnie Best

    I remember reading the first edition of Dan Shafer's book "Designing Without Tables". It seems he has paired with someone else for the second edition:

    I'm a big fan of standards, but there are just some "stretchy layouts" that can't be done with CSS alone. However, if you through a little javascript in the mix, you can give that table-layout-feel by resizing divs based on browser width and height and by firing event handlers during the onload and onresize events.

    I've spent a lot of hours doing layouts with with CSS and javascript that could be done easier with tables. It get easier, but sometimes it can be a real pain.

    Maybe the markup language needs a <stable> element standing for style-table. This would explicitly differentiate it from a "document structure table". I mean why not? Div tags aren't really contributing to the structure of the document. They're there for containing document elements so that CSS and Javascript can located and manipulate portions of the document; why not have a table-like-container for doing same thing? Tables are cool cause they're stretchy without javascript.

  4. Ed DeGagne

    Until the inconsistencies between browsers go away (I am not holding my breathe), I would fire a developer on my staff for taking 3-4 days to come up with politically-correct, table-less site design when it could have been done using tables in 3-4 hours.

    There is way too much argument about the subject, kinda like argueing over whats better VB.NET vs. C#.NET.

    A good approach is to use both in your designs.

  5. Kevin Lamping

    I think it's a matter of give a little here and get a lot later. With table-based layouts, sure it's gunna be faster at the beginning, but maintaining the site becomes a beast. Redesigning it would take ages longer than simply changing a CSS file. But if you're not going to be doing any updates to the site, then it does make more sense to use tables if you're more familiar with them.

    You also have to remember what the real benefits of standards based design are. While they don't guarantee a more accessible site, it's much easier to make a site accessible without layout tables. Also, tables are much more code heavy than semantic code.

    If you need to get something out the door and forget about, then do what's fastest, but if you can use the opportunity to learn something new then do it. Plus it makes it easier to code when you run across the problem next time around.

  6. Nicholas C. Zakas

    Kevin - I completely agree with your points. My main argument is that in the world of enterprise web application development, radical redesigns barely happen. Most of the time, you have a UI design that you need to implement. That design won't be changing for a long time, so the next time it has to change, there's enough time to go back and rearchitect the frontend. Consider the Yahoo! Mail Beta, for you think a change in CSS would do any good? Chances are, if they want a new design, they'll go back to the drawing board.

Understanding JavaScript Promises E-book Cover

Demystify JavaScript promises with the e-book that explains not just concepts, but also real-world uses of promises.

Download the Free E-book!

The community edition of Understanding JavaScript Promises is a free download that arrives in minutes.