One of the biggest annoyances I ever see in a website’s source code is layers upon layers of complexity. 20 nested <table>
s, 30 nested <div>
s – what’s the difference? Building a consistent and semantic website isn’t just an issue of whether or not you’re using valid code or mistreating a poor table by filling it with non-tabular data – it’s a question of whether you’re using logic to decide what element should be used to represent your content.
How deeply does a piece of information actually need to be buried in your document? Well, optimally (and arbitrarily), no more than 7 layers:
html
: Really, not a lot of choice here.body
: Again, pretty well obligatory.div id="container"
: A container div for your content is common and reasonable. Although not absolutely necessary, the use of a container div greatly expands your ability to determine what belongs inside and outside the overall design.div id="content"
: A div to contain content is eminently reasonable.div id="entry"
: In the case of blogs, keeping each individual post semantically separated is perfectly logical.div id="entry-content"
: Again, in a blog, separating your post from your comments area is logical.p
: Or a heading tag, etc. The bulk of your content should be contained at this level – only seven layers deep.
This list is a highly simplistic representation of what should really be represented in a tree format, but ideally speaking almost any content of your website should be accessible inside those seven containers or some other sequence of equivalent containers. There are exceptions, of course – more complex websites have more complex needs. A blockquote will immediately put content one layer more deeply buried. But compared to what is common out there in the web wilderness, descending to 8 or 9 layers of containment is insignificant.
When it comes right down to it, if you can’t justify something semantically, you should consider whether you can do it in another way. If you’re adding another <div>
just for the sake of adding a pretty border, why not look for another way to do it? A lot can be done with carefully designed CSS (Cascading Style Sheets) selectors. (Sometimes you can’t; it’s OK to add an extra <div>
some of the time.)
The more complex your code, the more difficulty you’ll have in altering your design, in tracking down bugs, and in repairing errors. Keeping it simple is in your own interest as a designer, for the sake of efficiency, at least, if you can’t come up with any other reason. There’s no need to sacrifice your design; but it’s worthwhile to always look for the simplest alternative.
dani
My web designer & developer friend said, if some clients need a website in a quick time, they would rather choose
table
s thandiv
s.Mike Cherim
D’oh. So you did. And right you are with the seven. 🙂
Joe Dolson
I did say “inside those seven containers or some other sequence of equivalent containers”. I just didn’t list out all the possibility…I should create a graphic which illustrates a more substantial version of this concept – might help to portray it visually.
Thanks!
Mike Cherim
Excellent reminder for developers to keep it lean, though I might also add it’s okay to use the container divs “header,” “sidebar,” “navigation,” and “footer,” assuming a typical two-column layout, as you suggested. But your point is well taken all the same. I’ve seen layouts with waaay too many divs that were completely unnecessary.