Seb Frost 21 December 2006 OK, so I’ve had a quick play, and it does indeed seem to work pretty well. Nice and quick to put a layout together, nice and stable across all browsers I’ve looked at (and I don’t care much about the ones I haven’t, so long as it’s readable which I assume it is). But it grates with me. I mean come on, in the example given we have 5 levels of nested divs, and 14 divs to create 8 areas of content. The classnames are also horrible and not exactly easily remembered for someone starting out with this. They’re also a little counter-intuitive – when I looked at the source before reading the article I assumed “doc3” was designating a 3-column layout for example. Maybe I’m just worried that this is going to simplify one aspect of my job so much that anyone will be able to knock out a semantic, table-free layout with no experience? ;) I think one of the biggest problems in my mind is that this example (whilst complex in layout) is actually very simple – there’s no backgrounds, padding, different margins, overlapping elements etc etc that a client will ask for. It works nicely for a basic example with no styling, but I feel it’d actually be a nightmare to work with once you start trying to put a design into it? And the use of css “hacks” worries me as well, I see both the underscore and the * hack used in this file – have we not learnt anything since IE7 came out? Do yahoo not think conditional comments are the way to go? If they have an article on this issue somewhere I’d be interested to see it. But the biggest problem has to be those nested divs. They make me shudder they do. I could make the same layout in considerably less code using a table, and it’d have guaranteed browser support, and would be very easily maintainable by someone who wanted to (for example) change the width of a column. What have we gained by going from a simple table to a complex div-soup?