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. Ted www.tdrake.net P.S. Someone in the office just mentioned using the marquee tag. I need to sound the emergency siren and get to work. Some reasons for div-itis: 1. Columns. "table cell => div" is wrong, but usually "columns => divs" is correct. 2. Boxes. The designer wants to put a box around a group of items. There might be a heading, a list or two and a paragraph, with border and a background. You could do this without a div (for example, by setting side borders on all the items, and a top and bottom borders on the first and last items respectively), but it's easier to just wrap it in a div and give it an id and a single style. And since box = section = div, it's the correct thing to do anyway. 3. Multiple backgrounds. 4. Expandability. Sometimes you know you have only one item in a box or a column, and you know you don't need a wrapper div. But you can bet that in a couple of months the designer/editor/cleaner will want to add a more items. So you build the structure to grow. 5. Box model work-arounds. You want to give an item a width, some padding and a border. You could use some CSS hacks, or you could just set the width on a wrapper div, and the margin/border/padding on the item itself. e.g. with columns, I set the width on the column div, then set the margins/borders/padding on the contents. 6. Laziness and deadlines. Sometimes it takes a lot of effort to make things simple. Not always worth it. cheers -- Geoff Pack Developer ABC New Media ****************************************************** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list & getting help ******************************************************
