Tables vs. Div Tags

By Shamus Posted Friday Mar 2, 2007

Filed under: Links 17 comments

In yesterday’s post I had some fun at the expense of XML coding standards. I linked Eric Meyer in that post. Upon later reflection, I thought this might be seen as a little rude – akin to linking Steven in a post lampooning anime as trivial cartoons and a waste of time. He was a good sport about it, and if I irritated him he didn’t let on.

I admit that my post was mostly just me mocking what I do not understand. A few people pointed out some perfectly good reasons for coding standards and what they have to offer a web developer. I know coding standards are very important in C++ (my day job, as it were) and and I would balk if someone suggested that coding style was just needless fussing. If you mean to maintain a couple of millions of lines of code, you had better have some sort of clearly-defined standards or those lines of code will very quickly devour you. You will be a lion tamer who just showed up without his whip and covered in barbecue sauce. You’re screwed.

I’m sort of getting my head around the concept of keeping the information seperate from formatting, and while I would never try that myself I admit that I’m not exactly dealing with a huge collection of pages here. (I coded this theme pretty much from scratch, and when I did so I thought of it as writing PHP, not HTML.) The need for this thing probably emerges as the job gets larger. Following strict standards for a site like mine would probably be like hiring an architect and a contractor to build a wooden crate.

Anyway, I pretty much get it up to a point, although there is one thig I don’t get, which is replacing TABLEs with DIVs. Maybe a CSS Jedi can explain this one to me. Most WordPress themes – as in, 99% of the themes I’ve seen – use DIVs for layout. The problem is that divs and tables have different failure modes. The typical theme is something like a page with a 500 pixel column and a 200 pixel sidebar. With divs, if the unwitting user posts an image that is 501 pixels wide, the sidebar gets bumped all the way to the bottom of the page. Or shift to the opposite side. Or suddenly go underneath the main column. This can be maddening for the user to figure out. Worse, this is really where browsers diverge in behavior. It might work just fine in Firefox, but in IE the sidebar will go missing. If that sidebar is used to help put other stuff into position, then very quickly the entire theme collapses like a house of cards and you’ve got content all over the place. But only in some browsers. This is very common, and the reason I abandoned public themes for something I made myself. I got tired of capricious puzzle themes that would spew content when they broke.

With tables, the wide image will just force the cell to go a little wider. Maybe this will introduce a seam elsewhere. Maybe it will bring about a few pixels of horizontal scrolling. Maybe it will work just fine. In any event, the cause of the problem is much easier to spot. I couldn’t figure out how you could reproduce this more graceful behavior using CSS. Maybe CSS isn’t robust enough to do this, or maybe there are attributes theme authors don’t know how to use properly. Keep in mind that when you’re designing a theme, you’re writing code to be used by people with a lot less expertise than yourself, who may not know the “rules” of your theme. Graceful failure with a clear cause becomes an important issue.

Maybe this isn’t so much a problem with standards as it it people adhering to standards when they shouldn’t.


From The Archives:

17 thoughts on “Tables vs. Div Tags

  1. Martin says:

    I hear you, and agree on many points. That being said, there’s a nice little demonstration of separating data from markup called

    Quite simply, the rules state that you cannont change anything about the html page, but you can futz around with the linked css document, and of course upload your own images. There’s some inspiring stuff in the archives

  2. Rask says:

    It may be a minor thing, but IE doesn’t like javascript code inside tables.

  3. Kris says:

    Shamus, I spend a lot of my life doing web programming, and there is a lot of capabilities in CSS that can’t be acheived with tables. Unfortunately, due to a lack of standard implementations on the browser side (IE6’s implementation was abominable), it’s extremely difficult to get a single style-sheet that will work across multiple browsers. IE7 is a great improvement on this, but still not perfect. Normally I end up having to have two seperate stylesheets, and based on the browser serve up the appropriate style sheet. Normally one for IE6, and one for “Everyone else”.

    One oddity of IE6 (I haven’t tested it in 7), is that if you give something an absolute position, with a top and bottom of 5%, it will not stretch to fit 90% of the visible window from top to bottom. It will use a 5% top and completely ignore the bottom value. In Firefox/Opera/Netscape, etc, it behaves correctly and stretches between the two points.

    This among other things makes Tables an easy alternative, but CSS does provide some amazing features for dynamic content. Honestly, if you’re not making use of the features, why bother? However, as far as “Graceful failure” goes, there are a lot of additional properties that help with that. You can adjust the behaviors of any overflow for every element in your page. People just don’t.


  4. The CSS {display: table} declaration should provide the same kind of formatting as HTML tables, while separating formatting from content. There’s just one problem: a certain big dumb browser doesn’t support it, making it effectively useless.

  5. Although I have known this fellow longer than almost any other living human has, he still amazes me!

  6. Dan Morrison says:

    I’ve found that overflow:hidden on the offending too-wide div seems to patch that particular problem pretty well.
    Maybe that’s the secret you were looking for.

    It can introduce a small problem with keyboard scrolling (pageup, pagedown) if your page focus is in the text itself sometimes however.

  7. Shamus says:

    Lynne! You can’t imagine how happy I am that you discovered my little site. Bless you. I hope you and D. are well. :)

  8. Michael says:

    overflow:hidden is, as Dan suggests, supposed to fix the problem you’re having.

    I use CSS if I need to affect a page programmatically and tables if I’m in a hurry or want to prototype something.

    In big database apps, it’s very important to separate the data layer, the business logic layer, and the presentation layer, because they need to change at different rates. If you hardcode daylight savings timeinto either your web app’s javascript or a stored procedure on your database, you’ll be scrambling to find it and fix it when congress meddles with it.

  9. Pixy Misa says:

    I've found that overflow:hidden on the offending too-wide div seems to patch that particular problem pretty well.

    It prevents the content from wrecking your layout, but it doesn’t do the adjust-to-fit that tables do. And even though the content can’t wreck your layout any more (which admittedly is pretty important), minor changes to CSS can still cause huge side-effects.

  10. me says:

    Ok, I started with a webdesign company as a content writer, I now have picked up all the skills of design, writing, some techinical bits. I don’t mind admitting that my skills are somewhat haphazard (Ok, MySQL is a database, but what does it DO?!), I have only recently dicovered how to make css files and use them properly, and when making or modifying sites, I find DIV to be a real problem.

    Don’t get me wrong, I think it looks great, but spare a thought for the poor fellow who takes the DIV template that you have just made and tries to put the content into it without knowing how it is constructed. This goes for many of the CSS templates on the ‘net, great, you can buy one for x amount of money and it will look great, but if it stops working, I don’t know how to fix it.

    At least with a table you can see what is happening, even if you don’t know how to $£%^&@@ing fix it.

  11. mockware says:

    I didn’t get into using style sheets until I started coding pages for 10 foot interfaces for Mediacenter browsing. In that case it helps with consistancy. All the buttons look the same and act the same. I’d say the tradeoff comes with how many widgets you end up having to work with and how much consistancy between widgets matters to your site.

  12. I’ll just parrot the “overflow: hidden” comments, but also say that I’ve never had to write separate CSS files for different browsers to get consistent layout. I simply use the techniques I’ve picked up at places like and always use them.

  13. Dave says:

    If your site ain’t broke.. don’t fix it.. Ignore the pesky machine telling you to change.. it is a machine… you .. are not? .. If you don’t follow the standards.. eventually it will be hard to view your site.. then it will be come a mystery site.. that only those that know how to view it will see it.. then it will become legend.. then…?

  14. Mark says:

    There are two major reasons to use divs instead of tables. One is that it produces cleaner code that is more descriptive of the content (i.e. semantic markup). Two is that (in theory) you can completely change the layout of the page without touching the content.

    Both of these are mitigated by non-standard browser implementations (which requires all sorts of CSS hacks which sometimes involve changing the content and making it less descriptive, among other display bugs like you’ve already noted) and in your case, the use of a CMS (wordpress) makes some of this stuff moot. A CMS is also basically separating content from design, so CSS becomes a little less necessary.

    There are still benefits to CSS if you can work it out. As I said, I’ve been working on converting my site to CSS. Part of this is just that I do it for a living, so I should keep myself sharp. But I also wouldn’t mind optimizing my pages for printing or for mobile browsers (i.e. phones, etc…) It might also be a good idea to allow visitors to choose a layout or color scheme (i.e. high contrast/low contrast or large type/small type). This is perhaps overkill for a blog, but still.

  15. hmm, *strong* is actually older than *b* … because *strong* asks for your implementation, *b* just bolds the content. The same with *em* and *i* — though it is fun to see somethings seem to come full circle.

    At least tables are better than frames.

    Really enjoy the comics, btw.

  16. Steve says:

    [Stephen] But what’s the diff? Just because a speaking browser needs to represent the content differently, there is no real semantic difference between the *b* and the *strong* tag except that one takes longer to code. The semiotics of the thing don’t change. Why not simply respec the *b* tag and leave the *strong* deprecated where it belonged :o)

    Admit it: even on a handheld the *strong* tag is going to be rendered in bold type. It’s not like you can’t associate the same CSS with a *b* tag as the *strong* tags, and in most large enterprises I’ll bet real money that’s exactly what they do to get backwards compatability.

    This is typical of any computing standards body. They always get caught up in the bloody minutiae and lose sight of thew trees.


  17. Steve says:


    Thank you Mr Brain.


Thanks for joining the discussion. Be nice, don't post angry, and enjoy yourself. This is supposed to be fun. Your email address will not be published. Required fields are marked*

You can enclose spoilers in <strike> tags like so:
<strike>Darth Vader is Luke's father!</strike>

You can make things italics like this:
Can you imagine having Darth Vader as your <i>father</i>?

You can make things bold like this:
I'm <b>very</b> glad Darth Vader isn't my father.

You can make links like this:
I'm reading about <a href="">Darth Vader</a> on Wikipedia!

You can quote someone like this:
Darth Vader said <blockquote>Luke, I am your father.</blockquote>

Leave a Reply

Your email address will not be published. Required fields are marked *