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 div
s 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
andSPAN
elements, in conjunction with theid
andclass
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, thelang
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.