Curing my Divitis
Tuesday 25th November 2008
I thought I was doing things the right way. I was wrong. I had divitis, and I didn't even know it. But it can be treated, even cured. For years, designers used HTML tables to create easy to manage layouts, to match their designs, despite the fact that they were only ever intended to display tabular data. Finally, when widespread support finally came for CSS, we moved on to more semantic markup, with use of holding div tags floated and positioned to generate the desired effect. Sure, this came along with the need for hacks to cover up inconsistencies between different browsers, but we looked down our noses at those still using HTML tables and cited web standards. But as it turns out, over use on non-semantic "presentation" tags (span and div, both have no actual implied meaning) can be almost as much of a sin as the one we left behind.
Difficult to follow code, large filesize (one of the major drawbacks of table layouts), and cumbersome meaningless markup are the main side effects of the transition from table based to div based design. Trying to recreate the possibilities capable with tables to divs at first can seem quite simple, but still not ideal. Basically, with each element that has a particular position or background (or behaviour), we tend to wrap that element (or group of elements) in a div, slap on an id and reference this to death in the external css file. To achieve more interesting backgrounds (such as multiple gradients or rounded corners) I've seen code where the designer has thrown on 3 or even 4 presentational div tags to achieve the effect. This affliction has been imaginitively called divitis, and it effects a large number of web designers. It quite simply involves a tendency to wrap anything and everything in a div, making what's inside easier and faster to position and style. I've always thought that I managed to avoid this kind of needless over nesting of div tags, but recently enough it hit me that I too was a divitis sufferer, when I was setting up my html markup for a project, and saw the following:
<div id="print"> </div>
<div id="header"> </div>
<div id="nav"> </div>
<div id="content"> </div>
It just occured to me that it wasn't right. So I looked at how I could improve the code. It turns out that I didn't need the pagewrap (which can be quite useful depending on the complexity of the background design) because the design was rather simple. So I saved on that for a start. The "print" tag is contact details displayed at the top of a printed website, and it's a company policy so necessity meant I left that where it was. I discovered that my header tag contained a link, an image and small list, which didn't require wrapping (and it actually made more sense to give them their own ids anyway.) The nav div contained one block element, a list, so I could remove that container and just style the ul as needed. The content div is a handy one to have, just in case you need to float elements and for attaching editable areas or a cms, so I left that one in. It could've gone either way though. And the footer div was another list. When I took the time to go through the code and strip away the needless presentational tags, I was left with these:
Everything else was pure semantic markup (with perhaps a few too many hooks/ids, but that's a discussion for another day). Much better, and as anyone who has dealt with an excess of divs will recognise, with only two divs, not nested, we remove the horror that is trying to find the corresponding closing tag for a box that you are editing. Many times I've been editing someone's code and came across :
Most of the time it's not even indented! The odd time someone might throw in some comments after the closing div to say which one it is, but although helpful it's not ideal. Prevention is better than cure, and if you've got this many nested presentational tags in your code in the first place, you're probably doing something wrong.
It is a hard convention to adhere to though. It takes time to really investigate design and dedicate yourself to optimising the code, but it is worth it in the end to see just how little markup can be used to achieve the same effect. Having said this, I often slip into the old habits of throwing in div after div, due a lot to laziness or time constraints, but I think twice about it now and in many cases it tends to be a compromise. It's a matter of getting into the habit, and I'm hoping that in time to come my divitis will be a thing of the past.