XHTML/CSS

CSS is perfect. Browsers are imperfect. I disagree with the idea that adding in things like redundant DIVs to acheive effects across browsers is equivalent to a lazy hack in programming. A lazy hack, to me, is something you do because the right fix is relatively expensive. Extraneous markup is introduced into XHTML because different browsers make different mistakes but users shouldn't have to know about it.

And the literary moose really pushes the envelope for what is do-able with CSS right now. The problem isn't just what's in the realm of capability, though. Yes, you can use acrobatics to create pure CSS rounded rectangles. By the time you're done, in terms of time and markup and CSS that were necessary, you may as well have used a table and a few images to do that trick (with the exception that it gums up table semantics for that page, but like I said, that semanticity problem has as much to do with limited definitions as anything else). Don't get me wrong: I understand that proof of concept tricks are useful. I've tried a few myself. It's just that pushing the envelope is probably less than half of the equation -- the real questions are if the common case is easy/powerful.

adamrice: What about selectors like "blockquote>p", "div#content *", or "h1+h2"?I mean, you can't say "this block should be adjacent to that block" ... the ability for which tables are still in use.You could do this using Z-indexes and absolutely-placed images.Yes, but then the images must be elements on the page. Some images are part of the content and are okay as elements. Others are purely presentational, like fancy borders or rounded corners. These should be in the presentation layer, but background-image: is usually not good enough.

You can't specify that elements should be adjacent, or otherwise have their properties be dependant on one another.Really? What about selectors like "blockquote>p", "div#content *", or "h1+h2"? Those give you descendant and adjacent elements (although there is no reverse-adjacent, which could be handy. Simple calculations would be nice.For example, it would be nice to be able to add images all over the page (background-image: does not suffice)You could do this using Z-indexes and absolutely-placed images. And http://www.literarymoose.info/=/css.xhtml really pushes the envelope for what is do-able with CSS right now.

I'll agree on #1, but I think #2 has been bandied about for CSS3. As for #3, doesn't the ill-supported "content:" property promise to do what you want? And CSS3 has much deeper border options, thankfully.

DrJohnEvans, I think that's the entire point, that it's a complete hack since you can't make really sophisticated designs without slashing and burning the markup. If CSS were more powerful, you wouldn't need to add lots of extraneous markup to create Zen-like designs. CSS has a few major deficiencies as I see it:You can't specify that elements should be adjacent, or otherwise have their properties be dependant on one another.You can't do simple arithmetic. Imagine if you could do something like:#left, #right { width: 200px; }#content { width: 100% - 400px; }.That would make multi-column layouts much easier, eliminating 90% of the cases where people rely on tables.You can't add presentational elements, leaving you with limited styling options. For example, it would be nice to be able to add images all over the page (background-image: does not suffice), or surround an existing element with multiple <div/>s to give it a multi-colored border.Any one of those would make CSS an order of magnitude more powerful. They could all be used to enable grid-based layouts without the use of tables. Personally, I would be happy with #2, and it would appear a straightforward addition to CSS.

Just echoing what jragon said: the redundant <div>s in the Zen Garden XHTML file are pretty specific to the Zen Garden's design. It's not a hack; it's Dave Shea trying to give hundreds of designers as much freedom as possible when working with a single, static XHTML file. You'd never have this situation on a site in which the design team actually had access to the XHTML.

To me, xhtml/css validation is shenannigans, but the philosophy is an important and userful one. In a nutshell: you don't know what browser, screen size, disability, or much of anything else about the user. So make websites that look nice under your ideal conditions, and usable under your least ideal conditions. It's very zen. It will never be exactly the way you want it, so it's best not to want it to be very exact.

Honestly, in most HTML/table based sites with a good CMS, the structure and presentation are already separatedThis was JWZ's complaint when he tried his hand at CSS. Here's the thing: it's separated at the back-end, but it is not separated as the rest of the web sees it. So in terms of, say, search engines extracting useful information, non-semantic markup puts them at a disadvantage. The way those pages live on the web is significant.