Coming to grips with divitis

I think you go through stages of CSS/XHTML maturity as you learn how to move away from tables to table-less design.

Our first instinct is to use divs the same way we used tables. It feels safe to load up the page with structural divs. That’s ok, especially if it is what helps you get from x to y.

However, you will get to the point where you realize the first CSS based sites you built had too many divs and you start looking for ways to place the styles on the unordered list or paragraph instead of wrapping those elements in a div.

I still see a valid reason to have divitis. If I am building a site that has to be flexible, modified by a large group of people AND uses server-side includes, I would rather make those include files self-contained units.

Sure, I could remove the container div on many of the includes, but I prefer to know that if an include is added to a page, the elements within it are not going to inherit the styles of the page’s container. Does that make sense?

Now, the goal of a medium to advanced CSS-based programmer is to find the elegant balance of essential divs, spans, ids and classes. Consider it a challenge.

I sometimes cringe when I see divitis. I sometimes chuckle. I even at times yell, “hey Brian check out this site’s chronic divitosis!” But let’s face it, this is an evolutionary process and those of us that have been doing it for a while need to remember what it was like on the first pass.

Disclaimer: don’t forget the horrible, horrible, horrible, horrible divitis and absolute-positionitis generated by some of the Office software and CMS systems. I once looked at a form that had hundreds of inputs and labels in individually positioned divs. That wasn’t the programmer’s fault. We just didn’t have time yet to build a new generator from scratch.