Jump to content
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?