Is Using Lots of div Tags Really That Bad?

Our latest book — the one with the controversial title — has caused much debate and more knee-jerk reactions than a bucket of frogs at a barn dance. A comment I’ve seen posted frequently is that “replacing table tags with divs that display as tables is no different; you may as well just use tables.” The argument is interesting because it sounds like the commenter is implying that the only reason not to use table tags is the number of tags involved.

I’m going to stick my neck out and say yes, even if you just replace all your table, tr, and td tags with div tags that display like those table elements, it’s better than using HTML tables for layout.

No one is negatively affected by the overuse of structural div tags. The same can’t be said for the use of HTML tables for layout.

A web page that uses nested tables for layout will be difficult to print, difficult to view on a mobile device, and difficult to navigate for users of screen readers. A screen reader application will often stumble over nested HTML tables, announcing something like “table with 5 rows and 2 columns” as it enters the table content and “table end” as it leaves. The same web page using nested div elements can be styled to stack neatly for print and viewing on a mobile device, and screen readers ignore div elements.

By using HTML tables you are implying that the contents of each cell relate to the contents of other cells in 2 dimensions: in the same row and in the same column. On the other hand a div implies no such relation with other div elements. It’s simply content scaffolding, and no meaning is derived from their use.

OK, blindly replacing all table-related tags with div elements may not be the correct approach to the problem, but to say that it is “just as bad” as using HTML tables for layout is wrong. HTML 4.01 defines the div as a “generic language/style container” or more specifically:

The DIV and SPAN elements, in conjunction with the id and class attributes, offer a generic mechanism for adding structure to documents. These elements define content to be inline (SPAN) or block-level (DIV) but impose no other presentational idioms on the content. Thus, authors may use these elements in conjunction with style sheets, the lang attribute, etc., to tailor HTML to their own needs and tastes.

So we can use div elements to define content blocks; sounds like using nested div elements for structuring content is perfectly valid. As long as you don’t use div elements in place of more appropriate ones like headings, paragraphs, blockquotes, lists, and of course, tables for tabular data, then you’re doing fine.

The approach you take when creating a layout using HTML table elements is to first lock-in the layout in HTML before you style your web page. This is wrong and flies in the face of established best practice: separate your presentation from your content.

This is completely different to the CSS layout approach, even when using a lot of div elements. For example, I could wrap all of the content that represents site branding in a div tag, and all of the content that represents additional site information in a another div tag. The fact that, in CSS, I may apply a style that places the site branding at the top of the web page and the additional site information at the bottom, is not important yet. At the layout stage I might do that, or I may use the CSS table-related display values to make them into columns or rows. The markup can be styled in multiple ways because the approach does not lock-in the layout in the HTML markup.

Free book: Jump Start HTML5 Basics

Grab a free copy of one our latest ebooks! Packed with hints and tips on HTML5's most powerful new features.

  • http://panesofglass.org/ aranwe

    I think <div> tags are infinitely better than <table> tags; however, you are still mixing presentation and content. For instance, how would you layout the following markup in three rows with one column on top, three columns in the middle, and one on the bottom:

    <html>
    <head>
    <title>Demo</title>
    </head>
    <body>
    <!-- start first row -->
    <div id="header">
    <h1 id="header">CSS Tables Demo</h1>
    </div>
    <!-- end second row -->

    <!-- start second row -->
    <div id="navigation">

    <!-- start first column -->
    <ul id="main_nav">
    <li></li>
    <li></li>
    </ul>
    <!-- end first column -->

    <!-- start second column -->
    <ul id="sub_nav">
    <li></li>
    <li></li>
    </ul>
    <!-- end second column -->

    </div>

    <div id="content">

    <!-- start first column -->
    <ul id="main_content">
    <li></li>
    <li></li>
    </ul>
    <!-- end first column -->

    <!-- start second column -->
    <ul id="sub_content">
    <li></li>
    <li></li>
    </ul>
    <!-- end second column -->

    </div>
    <!-- end second row -->

    <!-- start third row -->
    <div id="footer">
    <p>Footer information</p>
    </div>
    <!-- end third row -->
    </body>
    </html>

    That certainly looks plausible, but if I have to use additional markup, I don’t know that I’m sold. I know I could restructure my markup to make it all play nice, but what if I want to change my design later? Thus, I’d rather set my markup and use CSS to display it as I want. I’m using this approach on a client’s site to great effect, except for maybe the sub_nav, which I think I moved to the footer region. (I know that breaks my earlier statement, but I don’t purport to be a CSS guru, either.)

    If you really need to get extra <div> tags in there, why not use an XSLT stylesheet to attach the additional <div> tags and set your CSS stylesheet?

  • http://panesofglass.org/ aranwe

    That looks awful. I’m trying to post the code sample again:

    Demo

    CSS Tables Demo

    Footer information

  • Anonymous

    It is not as bad as, but it is still a lesser bad.
    Using too many <div>‘s makes bloated, hard to maintain code.

  • ravidor

    It is not as bad as, but it is still a lesser bad.
    Using too many <div>‘s makes bloated, hard to maintain code.

  • Azeroth

    Oh, come on – if you have huge design with blocks over blocks, you will have hard to maintain code no matter what.

  • CSS_is_not_the_end_all_be_all

    Just coming off of two projects working with the pure css code of two different vendors (to reskin their applications), I have to say, working with someone else’s uber-nested <div>s is a huge p-i-t-a. In one app, the design kept breaking in IE6 on certain pages, before we even dug our paws into. Doing a quick count on one page, I discovered there were 28 opening <div>s but only 25 closing </div>s. Mozilla browsers were handling it gracefully, but IE6 was completely falling apart (and our stats showed that a good 30-40% of our customer base for the site in question is still on IE6, so, we couldn’t ignore it). Many of the divs were unfortunately not id’ed or class’ed (just plain ole “<div>” doing mysterious things – or mysterious nothings), so, even with my trusty Firebug, I was resorting to inserting randomly placed closing </div>s to try to cap off the problem. The other app was even worse.

    From these two experiences, I can say one advantage of working with tables is that the tags themselves are cues to the structure of the code. Even bad nested table code is easier to repair than bad CSS.

    I’m not making a case for tables specifically, but it seems to me that CSS has yet to prove a suitable solution for pure presentation layer code, and we’re perpetually arguing a “lesser of two evils” scenario between tables and css, when the mighty brains that technologize the web should be looking for a different solution altogether.

  • http://www.galaxyinteractive.net galaxyinteractiv

    This seems like it would take alot of extra time?

  • arts-multimedia

    I have seen pages containing 128 divs. folks simply are too lazy to clean up Some 2 reasons to curb the use of layout elements, be it divs or tables: 1: processing time for the browser. 2: readability and maintenance.

    css tables have a structural problem tha

  • okparrothead

    I’m all for divs. I was sold when I learned that using the same divs and different stylesheets, I could have navigation across the top (plus a little javascript for IE6), down the right side or down the left.

    With the same divs, the print stylesheet basically hid the navigation and the page was in outline form.

    Again with the same divs, I could use image replacement so screen readers could read the styled header tags.

    The code could be valid and all images not in the content could be added as backgrounds by the stylesheet.

    As I said, I’m all for divs. It truly separates style from content.

  • Justen

    You managed to answer right and wrong at the same time! Look, you don’t need a bunch of extra divs using css tables, that’s a nonsense assumption. You need the same amount of block elements as you’d already be using, and they should be properly chosen semantic HTML. Unless I’m missing something, display: table-cell should work just fine on any element. If your page is semantically structured and you have effective knowledge of CSS you will not need any unnecessary structural elements to achieve any layout you desire.

    Think about it this way: if you weren’t using table-cell, etc. you’d be using block (or inline, or inline-block as necessary) and dividing your page up into logical sections, then using positioning code to place it on the page. You’ll be doing the same exact thing now, except instead of floats and positioning you’ll be using a single display: declaration.

  • veg0matic

    Agreed: separating form from content is the whole idea. If you build a page as a table, you can’t later reposition row 2 column 3 below the table by changing the CSS; you have to rewrite the HTML.

    In aranwe’s example, it’s pointless to have an H1 element with id=header inside a div with id=header. “id” is intended for unique labels, so if H1 has an id attribute, wrapping it in a div with the same id is not only redundant, but confusing.

  • Gerardo Müller

    Greetings.

    Could somebody invent a program so that we poor amateurs could just chose by YSWYG how it looks in css or Html-table?

    It would be just wonderful.

    Thank you

  • Anonymous

    Isn’t the debate a bit hypothetical? Until a critical mass of users are on compliant browsers surely we have to stick with tables (or some more exotic css alternatives). My understanding is that MSIE6/7 don’t do “display: table-cell” and that accounts for a majority of web users. And once the world has migrated to compliant browsers an awful lot of websites are built with Dreamweaver (or similar wysiwyg) so we have to wait for those to wise up about css table code too.

  • rob1951

    Isn’t the debate a bit hypothetical? Until a critical mass of users are on compliant browsers surely we have to stick with tables (or some more exotic css alternatives). My understanding is that MSIE6/7 don’t do “display: table-cell” and that accounts for a majority of web users. And once the world has migrated to compliant browsers an awful lot of websites are built with Dreamweaver (or similar wysiwyg) so we have to wait for those to wise up about css table co

  • veg0matic

    the mighty brains that technologize the web

    “Become the mighty brain …”

    Whenever I’m analyzing someone else’s HTML (or Javascript or Perl), the first thing I do is re-indent everything. If some divs or other elements aren’t closed, the indentation gives you a clue which ones.

  • Bennie

    As an amateur webmaster I have been struggling with CSS positioning for a while. It gets a little easier with practice, but I cannot style a page without a lot of trial and error in adjusting sizes of elements and so on.
    I looked at a professional template recently and was completely amazed that it would work with only a very few divs and selectors. It appears that the more you can let CSS handle itself the easier it is to position elements where you want them. And I did learn that validation is no guarantee the page will look the way I want it.

  • Arlen

    Div-loading can bad, but only sometimes.

    The big issue with tables is they completely destroy the semantics of the page. When I’m reading table code I really have no idea whatever what this particular table cell is. It might be a content block, but then again it might be just a fragment of a block, or a margin, or a background piece, or…., well you get the idea. Table code is so hard to understand without detailed study that anymore I simply refuse those proposals, or undertake them only if I can rewrite them.

    The intent of a div tag is to group together related bits of content, when it’s used outside of that purpose it ceases to have any useful meaning, and again becomes difficult to comprehend and maintain. Now, if Andrews/Yank propose to use divs to group related bits together, I have no issues with their book (only with their seeming premise that grid-based design with CSS table rules is hard, because it isn’t).

    OTOH, if they’re simply proposing to change table cells for div and css table display rules on a one-to-one basis, then all I can see they’ve managed to do is exchange one difficult to understand and bloated system of blocking off content for another. Maybe they’ve made some progress, but I can’t see how it’s significant.

    My own practice is to intrude on the document with no more divs and spans than are absolutely necessary to accomplish the design. Any more is a waste of time, both on my part and on the audience’s. I’ve had to implement some designs that require a lot of extra divs (and I’ve always felt like washing my hands afterwards) because of one browser “feature” or another, but the more divs I’ve used, the greater the likelihood of some issue rising up to bite me in the butt later, so count me as naturally skeptical of anything that requires lots of meaningless tags.

  • http://panesofglass.org/ aranwe

    @veg0matic:

    So my example wasn’t perfect. I certainly don’t double up id values normally; that was a quickly contrived example. The point was the basic structure:


    <html>
    <head><title>Example</title></head>
    <body>
    <div id="header">...</div>
    <div id="toc">...</div>
    <div id="content">
    <div id="main_content">...</div>
    <div id="sub_content">...</div>
    </div>
    <div id="footer">...</div>
    </body>
    </html>

    Now, set the header in row 1, the toc, main_content, and sub_content in three columns in row 2, and the footer in row three. I know I can move the <div> tags around and put the toc in the content <div>, but suppose you don’t have that option.

    You can still do it without CSS tables, but I don’t know how to do it with CSS tables. If anyone has any pointers, I would love it.

  • http://tetlaw.id.au Andrew Tetlaw

    @Justen, yeah that’s right. I expect that once someone who is used to tables for layouts starts experimenting with CSS tables they’ll realise they don’t really need to match tag for tag.

    @CSS_is_not_the_end_all_be_all. Yeah a div without a class or id attribute does seem to be, at face value, redundant. Not sure how you’d style them usefully in that situation.

  • Garison

    it seems to me that CSS has yet to prove a suitable solution for pure presentation layer code

    I have to use additional markup, I don’t know that I’m sold. I know I could restructure my markup to make it all play nice, but what if I want to change my design later?

    Say what? This is what CSS is for. You need to take a look at csszengarden.com. It’s what convinced me to switch from table layouts to pure CSS. Yes, you have to take extra pains to structure your document correctly, and yes, to the untrained eye it looks like a bloated mess of nested tags, but the point of it all is that when you want to change the look of the your site, you need only change the CSS. You want that image on the right instead of the left? Change “float:left” to “float:right”. There’s no need to change the structure of your document.

  • http://www.brothercake.com/ brothercake

    Don’t forget accessibility – layout tables are semantically incorrect, which impacts on assistive technologies that rely on semantics to understand what content is.

  • nathj07

    The biggest problem is not which one to use but lazy use of it. Personally I prefer to but that’s because I think that tables are for tabular data and normal website is rarely tabular data – at least not without stretching that definition.

    However, if the developer/designer uses either option in a lazy manner you end up with the problems listed above – unclosed tags, or hideously nested tables. This first of these is easy to solve with a little care and attention to the code itself. Simply indent the code. By indenting code you can see which tags match up and which don’t giving you a more obvious and more reliable method of finding the missing ones.

    This issue though is nothing to do with tags but rather the laziness of the developer.

    All that said (in a somewhat waffling manner) I think we need to ditch tables for page layout, anybody using tables for non-tabular data should be quietly removed from the development community. Long live the !

  • nathj07

    oops, I forgot to escape my code tags, it should read:

    The biggest problem is not which one to use but lazy use of it. Personally I prefer <div> to <table> but that’s because I think that tables are for tabular data and normal website is rarely tabular data – at least not without stretching that definition.

    However, if the developer/designer uses either option in a lazy manner you end up with the problems listed above – unclosed div tags, or hideously nested tables, each with their own knock-on effects. This first of these is easy to solve with a little care and attention to the code itself. Simply indent the code. By indenting code you can see which <div> tags match up and which don’t giving you a more obvious and more reliable method of finding the missing ones.

    This issue though is nothing to do with <div> tags but rather the laziness of the developer.

    All that said (in a somewhat waffling manner) I think we need to ditch tables for page layout, anybody using tables for non-tabular data should be quietly removed from the development community. Long live the <div>!

  • nickobec

    Good grief I thought the tables for layout argument died years ago. Hard to maintain, a bugger to make minor changes to, not semantically correct and plays havoc with assitive technologies.

    When you first start with CSS you have heaps of divs and spans, everyone has a id or class name. After a while the number of divs decline and spans almost disappear, and you start writing clean semantic code

    You don’t need to give an id to every unique element, especially if it is the only child of another block element with an id. Why not #idofparent div or even #idofgrandparent div div? Why because if you give them semantic names, next time you or your successor have to maintain the code it makes sense.

    Almost every page I develop has a few extra divs for presentation purposes. Once all common browsers allow for multiple background images for one element, most will go, but until then I just name them appropriately.

  • http://www.cemerson.co.uk Stormrider

    I think you should use as few elements as possible, but if it comes to it, there is no problem with adding more div/spans to make things work. They are semantically neutral elements, unlike tables, so I don’t really see how the people who are arguing lots of divs is the same as using tables have a leg to stand on.

  • http://www.cemerson.co.uk Stormrider

    Oh, and I think complete separation of content, style and behaviour is a bit of a myth. All 3 get interlinked, preferably via classes and ids, but often not. CSS isn;t yet good enough to take ANY html and make it display exactly how you want. A site redesign very rarely doesn’t touch the HTML.

    It is always good to aim for separation, and use it as much as possible, but practically, complete separation is impossible.

  • watershed

    I’m going to stick my neck out and say yes, even if you just replace all your table, tr, and td tags with div tags that display like those table elements, it’s better than using HTML tables for layout.

    To cut to the quick, Andrew is right.
    To my mind the key is to follow Andy Clarke’s content out approach to markup as he advocates in his book, Transcending CSS
    Start with the content, considering carefully what semantic markup it warrants for itself. More often than not, this will give you sufficient structural hooks to implement the styling you want to achieve.
    In those cases where it doesn’t, add unsemantic block or inline tags that give you enough hooks – either directly or through unobtrusive JavaScript.
    Then style with the hooks you have.
    The point about table tags is that they are semantic and they shouldn’t be used for the unsemantic purposes of step 2 above.
    Case closed ;)

  • watershed

    Dammit, I thought my <ol> in the comment above would work but it got stripped. Step 2 is the paragraph that begins with “In those cases”.

  • dpages

    I’m still getting my head around this (I guess I’ll have lots of time as it’ll be a while before IE8 is dominant enough for me not to worry about IE6 or 7).

    I’m hoping that this won’t have too much of an effect on what I do. If if have a standard three column layout with:

    ——————————–
    Header
    ——————————–
    Nav | Content | Sub |
    ——————————–
    Footer
    ——————————–

    Then instead of using floats or absolute positioning to get everything in place, I just change the Display property for each existing Div. In my mind, nothing in my HTML has to change.

    I’m currently experimenting with Mike Stenhouse’s CSS Framwork, and if my understanding is correct, then the actual changes for the fundamental layout would actually be quite easy to make using his modular approach to CSS, and using conditional comments could keep IE7 and 6 quite happy. It’s something I’m planning to put my mind to when I get my copy of the book.

    Mind you, this is a bit of a bugger for Sitepoint if it means all their current books about CSS are redundant…

  • Jens Grochtdreis

    It is strange that you are starting such a useless debate at the end of 2008. Stan Lee would point it like that:”‘Nuff said!”

  • Stephen

    Now, set the header in row 1, the toc, main_content, and sub_content in three columns in row 2, and the footer in row three. I know I can move the <div> tags around and put the toc in the content <div>, but suppose you don’t have that option.

    Wouldn’t it solve the problem rather elegantly to put the second row, the meat of your page, into a containing “body” div? Then you just have:
    <div>header</div>
    <div>body</div>
    <div>footer</div>
    and within your body you have:
    <div>toc</div>
    <div>main</div>
    <div>sub</div>
    and each section can be styled 100% differently from every other section if you so desired.
    There must be a deeper question that I’m missing here, because multi-column pages of both fixed and liquid layout, with headers and footers, have been part of the CSS lexicon for a long time.

    There are a couple places on our corporate website where I “cheat” and use tables, but you could make the argument that those sections might constitute a table anyway, not necessarily a data table, but icon, description, download link in a table format. We call the header and footer through includes so we don’t have to change those even if we have to go in and alter the html code. Everything is designed to allow the greatest amount of sitewide layout change with minimal per-page alteration, and we can often accomplish those using Dreamweaver templates.

    By contrast, I’ve seen web apps that table everything, which allows strict control, but you end up with tds and trs for everything imaginable: rounded corners on tabs/buttons, spacers, micro-splits of data sections… I don’t see a good reason NOT to trade that in for CSS when our pages average maybe 150 lines of code, and 50 of that is SQL stuff that precedes the actual html.

  • http://autisticcuckoo.net/ AutisticCuckoo

    Yeah a div without a class or id attribute does seem to be, at face value, redundant. Not sure how you’d style them usefully in that situation.

    Use the power of CSS selectors! You don’t need IDs and classes on everything. CSS provides descendant combinators, child combinators, sibling combinators, adjacent sibling combinators and a host of pseudo-classes that eliminate the need for lots of id and class attributes.

    The main problem, as always, is that IE lags behind the rest of the world when it comes to CSS support. That’s not a CSS problem, but an IE problem. However, it’s still a problem.

  • lulabelle

    It sounds like there is some confusion about the use of table tags as opposed to div tags which behave like tables.

    Web design layouts are based on a grid structure and in order to display them we are currently being forced to use less than ideal methods to do so (namely floating). A grid can be much more sensibly laid out using the mental model of a table. Using CSS to do this means that we can do it by making a pseudo table without ever needing to affect the user or the html code.

    As I understand it, all “table” elements which are not specifically stated in the CSS are implied which means that if I describe a <div> as a table-cell in the CSS then the row and table elements are assumed to surround it, even if there are no surrounding <div>s. Therefore, no extra markup needs to be added.

    The fact that IE is preventing us from using this technique is a major drawback so we will have to bide our time somewhat, but in the meantime, we can arm ourselves ready to make our lives easier as soon as IE8 falls into common use. (and works like it’s supposed to!)

  • http://www.cemerson.co.uk Stormrider

    One thing I don’t like is the name ‘css tables’ – they are only called this as a hangover from the html table tag. A table is a semantic structure, and we are talking about using a presentational concept – it should be called something different to ‘tables’ when in the css context.

  • pierce

    Proper indentation is a beautiful thing. I stress that in all my programming and web-dev classes.

    veg0matic Says:

    Whenever I’m analyzing someone else’s HTML (or Javascript or Perl), the first thing I do is re-indent everything. If some divs or other elements aren’t closed, the indentation gives you a clue which ones.

  • watershed

    Good point, Stormrider – I agree – though it’s a bit late now.

  • http://panesofglass.org/ aranwe

    @Garison:
    I don’t think you looked at the (horribly mangled) markup I provided. I’m not using HTML tables. I’m talking about using CSS tables. I’ve never created a design with HTML tables and never will. I completely forsook web development early on because HTML table layouts were the “way to do it” and I hated them.

    @Stephen:
    Your suggestion would work and still maintain semantics; however, my question was how to layout the provided markup, not whether or not it was correct. I noted in my original comment that I’ve done that layout without CSS tables, but I am curious if it can be done with them.

    I guess my point in all this is that I don’t know that CSS tables will really be all that revolutionary. Sure, if your markup plays nice with CSS table-based layouts, then you have a much more direct and easy implementation ahead of you. Should you force your HTML to play nice with CSS tables? I don’t think so. I would agree with watershed and Andy Clarke that markup comes first, then the layout, which also agrees with Garison’s comments (even though I was misquoted).

    Put simply, CSS tables is a shortcut to clean grid-based design if your markup works with it naturally. Forcing markup to fit a layout scheme is just wrong.

  • Johhny2Bad

    Reading over the comments i noticed a common theme, although where talking about the use of css, divs and tables and how best to use them, the bottom line seems to be about readability and maintainance.

    If a document is indented as metioned and well commmented then readability and maintenance shouldnt be a proble.

    good indentation and commenting may not solve the problem/possibility that u may have to change large chunks of code to update the site but good indentation and commenting regardless of what methods you use should still simplify readability and maintenance

    i tend to adopt the software desgn approach even when designing websites/pages by first creating a PDL (program design language) which gives me a perfect template for commenting and organising my code for easy readability and maintenance.

  • Anonymous

    @Watershed

    Completely agree with Andy Clarke’s approach as well. After reading his book it totally transformed the way I look at setting things up from an HTML perspective.

    Unfortunately, certain limitations with CSS across the various browsers encourages people to just add the extra markup to make their lives easier.

    Justifiable or not, it’s just the way it is.

  • bsmbahamas

    since we are still using divs, and using css to mark the parts of the table, i don’t see the big deal, if we decide we don’t want it to be tabular anymore we remove the display: table from the css code, and it we could style it using the id like a regular div. seems to me that css could still handle the styling using an external stylesheet without having to edit the html page – keeping the style and content seperate.

    the article at digital point used but it could have been and we’d still be able to use css to say it is a cell, or later use it as just a plain old div belong to our fruit class.

    we don’t have to use cell, row, etc as the name of the class
    in the divs, but a or will always act like a cell or row in html, we’d have to edit the html to affect how they behave, using divs to build a tabular layout lets you control how they are styled in an external css file – so today they might be used as a table but tomorrow you could remove the table formatting from the css class without having to update your html code.

    so i think it is a step forward, but i doubt it will be adopted until microsoft gets rid of ie6 and ie7, since we can handle all browsers now using regular divs.

    hope this post makes sense

  • http://stevenjs.com/ stevenjs

    Now we have “politically correct” code, about which only a code junkie could care.

    I will continue to use tables for layout, not only because they make perfect sense as a layout tool (unlike CSS), are easy and intuitive to use, accomplish designs that CSS simply can not (let me repeat that CAN NOT), and I do not what a code-ist religiion that impoverishes design, but simply for spite.

    And more, I’d be delighted to kick every W3 pithead in the butt-hole that ever said laid down this “recommendation” and frankly derive immense personal gratification from stangling with me own hands every a-hole who has sought to turn this “recommendation” into the 11th Commandment.

  • dpages

    There’s nothing ‘politically correct’ about CSS. I happen to enjoy being able to change a design site-wide easily, and I think content structure should come first, and then presentation should follow, like with any other document.

    I think it’s important that search engines to be able to find and understand my content (accessibility is also self-interest for me and my clients, with Google effectively being the king of disabled users and, using CSS properly, most of my SEO is already done). It’s also reassuring to my clients that their sites don’t break the law with regards disabled access, and that I’m not putting barriers in the way of disabled people’s freedom to use their site, rather than hanging up the web equivalent of a ‘no entry’ sign.

    I like the fact that people can resize my pages in their browser, and the design doesn’t break.

    You’re right, there are probably table-based designs that are difficult to reproduce in CSS (although the techniques in the book bring those a step closer). But then there are designs I could produce using a big, one-page JPEG file that you can’t reproduce using tables, and that’s not a reason to start using them either.

    Personally, I also enjoy learning new techniques that I can use, as an intellectual challenge too. I like learning as an activity anyway.

    Of course, you’re perfectly at liberty to continue the way you always have, and I’m sure you’re also perfectly happy with your reasons for doing so. I just think history would have been a lot different if there weren’t people who were challenging the status quo and looking for better ways to do things.