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.