XHTML/CSS

July 15, 2004 3:57 PM

I want to believe in XHTML/CSS. I want my structure entirely separate from my layout. But I also think it might all be a big lie, and not because of browser difficulties. Please help clear my misunderstanding. Further explanation - your people call it "more" - is inside.

I'm redesigning an old site as a personal project, so I have no restrictions. I figured I'd take the opportunity to make a truly pure XHTML/CSS creation, no table layout, etc. So I head over to CSS Zen Garden where I remembered a beautiful demonstration of what could be done with one HTML page and many different style sheets.

Here's where they lost me. When I looked at the example HTML file, I saw this:

<!-- These extra divs/spans may be used as catch-alls to add extra imagery. -->
<!-- Add a background image to each and use width and height to control sizing, place with absolute positioning -->
<!-- There's a rather nasty colour shift bug with transparent GIFs in Netscape 6/7 and Mozilla v1.0 up to v1.3 (in which it's fixed), so make sure to test your work in these browsers. -->
<div id="extraDiv1"><span></span></div><div id="extraDiv2"><span></span></div><div id="extraDiv3"><span></span></div>
<div id="extraDiv4"><span></span></div><div id="extraDiv5"><span></span></div><div id="extraDiv6"><span></span></div>

Ok. They've stuck six extra divs because they may need them to add images in the future. Now, in the programming world, that's what we call a dirty hack. You can't just say "six oughtta do it" and move on. You need a way to incorporate as many images as a future design may require, or else you haven't really separated display from structure. What if my next design needs seven divs to get the job done? Whether that's unlikely or not is besides the point. I'd never declare a static array in code and write a program around "there probably won't be more than X elements...". You just can't do that. It's the definition of sloppy.

Looking at it that way, the idea of a "pure" XHTML/CSS site seems like a farce, since honestly all it seems like CSS is doing is giving us control over how individual HTML tags are styled, NOT over how a page in general is layed out and designed. CSS Zen Garden does it by using all sorts of strange tricks with DIVs to get the design they want. But I don't see how that's much different than strange tricks with tables, aside from keeping different files. And again, ultimately, if the CSS file can't dictate page layout by itself, structure and style were never truly separated, because you've got style sitting in your structure in the form of those extra DIVs.

I know a lot of very brilliant information architects and web gurus put this stuff together, so I figure I'm the one missing something major, not the other way around. Can someone walk me through this?

posted by tirade to computers & internet (23 comments total)

You've nailed it. It's just that css is a more useful dirty hack than html.
posted by y6y6y6 at 4:05 PM on July 15, 2004

In theory, CSS can do all the things you want. In reality, because support for CSS is imperfect in all browsers, and especially so in IE (which most people use), as a practical matter, you need to introduce a lot of these hacks. A lot of those nested SPANs, for example, are there to give designers hooks for a special technique called "Fahrner image replacement"--a simpler variation of which can do without them, but which (you guessed it) IE will not treat correctly.

You can even emulate table layout without table tags (self-link), but again, this doesn't work in IE.

There are scads of CSS references out there that give you skeletons for generating various page structures, etc.

CSS is good--don't give up hoope.
posted by adamrice at 4:19 PM on July 15, 2004

err, hope.
posted by adamrice at 4:23 PM on July 15, 2004

I made a lengthy comment in a previous similar thread, but to summarize:

Don't get caught up in CSS/XHTML as a religion or even an ideal. It's not worth your time to treat in that way.

What it *is* worth is learning as tool to add to your web development toolbox. It makes some things tremendously easier, and some previously nearly impossible things possible.

But don't also be afraid to go back to tables once you've learned the CSS discipline. They make some things tremendously easier too.
posted by weston at 4:47 PM on July 15, 2004

tirade, I think you're unfortunately (and very understandably) overestimating the promise of these technologies in abstracting out the page structure from the HTML itself. I see what you mean, and I'm sure you can find a lot of assertions that that's what it's supposed to do, but it's just not a realistic goal. (Certainly not right now, maybe not ever, given the constraints of a text-only medium that needs to deal with multiple flawed browser platforms.)

The real practical benefit of CSS/XHTML is in teasing apart what you could call the "presentation layer" from the "content". That's a great improvement over basic HTML, where you had to type the formatting tags right into the page, but as you've pointed out, that's a pretty diminished goal. Beyond that, as y6 pointed out, they offer a lot more flexibility in how you can hack stuff, but they don't really change the fact that you've still got to type a lot of your structure right into the page.
posted by LairBob at 4:51 PM on July 15, 2004

(And if you're ever going to do HTML email, you will need your full knowledge of HTML 3.2).
posted by weston at 4:52 PM on July 15, 2004

One more thing:

If you really want to abstract document semantic structure from presentation, you *can* do it with technology available today. XML is pure structure, and you can define your own formats.... and then use XSLT (or something else, if you want) to transform it to a presentational form, which might include as pure a XHTML/CSS encoding as you like, or HTML 3.2, or if you've got Formatting Objects down, PDF.
posted by weston at 4:54 PM on July 15, 2004

Um, maybe I'm misunderstanding, but I'm pretty sure all those DIVS at the top are not a failing of CSS but because that's how zen garden works. The idea is one HTML doc can be marked up using only CSS, so he made an HTML with more divs than necessary so people could make crazy designs with a lot more graphics than he used for his first set of designs.

But in general, you only write the number of divs you need into the page, just as you'd expect.

(and to second what others have said: don't fall into XHTML/CSS as a religion, but don't join the "All XHTML people suck" anti-religion, either. It's just a bit of technology, nothing to turn into a big debate.)
posted by jragon at 5:14 PM on July 15, 2004

The Zen Garden probably isn't the best site to showcase CSS as a means of separating the presentation layer from the content. It's intended more as a demonstration of possibilities than as an example of real world implementation.

That said, there are several benefits to writing more 'semantic' markup. Not the least of which is simplicity -- it's far easier to modify a stylesheet than it is to modify individual tags spread about an entire site.

There really isn't much you can't do with CSS. As an example this site (self link) is CSS/XHTML and essentially valid (I keep forgetting to add alt attributes to the thumbnails) but the markup is far simpler than if I had used tables. For me, that is the single biggest advantage of writing valid modern markup, it's easier and by making an effort to adhere to standards there is a baseline that doesn't exist with tag soup.
posted by cedar at 5:36 PM on July 15, 2004

weston, the comment you link to touches on what my next comment was going to be. I've actually been using CSS for years, so I know that it's useful as a convenience feature. I just never really sat down and tried to understand the "purist" notion of style/structure separation, and I was more than a little confused when I tried to work it out and found that there wasn't really such a thing. Especially when so many bloggers/web pundits/zeldmen were treating it like the holy grail of information architecture.

Before I read your linked comment, I was going to point out that CSS seems to do clumsily what a sophisticated content management/template system will already do almost perfectly on the server side. It's already pretty straightforward to keep your data in XML docs or a DB and use an application or script to give it an easily-variable presentation form upon transmission. As you said, even XML/XSLT seems potentially like a more sensible and flexible solution for handling presentation.

CSS offers more convenient and straightforward syntax for declaring layout, but relative to the hype that's a very tiny thing. Honestly, in most HTML/table based sites with a good CMS, the structure and presentation are already separated: the data is stored and structured elsewhere, and the HTML table design becomes the presentation layer. The two only become muddied and fused at the point of transmission. The benefits of self-describing data like XML on information transmission between differing systems is quite obvious, but it seems only loosely relevant to classic "web design" concerns.

Or maybe I still have too naive an understanding of this stuff and I'm missing the big picture.
posted by tirade at 5:59 PM on July 15, 2004

" As you said, even XML/XSLT seems potentially like a more sensible and flexible solution for handling presentation."

Now you done did it.

There is a case to be made that since browsers (well, at least one) aren't serving up XHTML as XML anyway, that the point is moot. For now.
posted by cedar at 7:44 PM on July 15, 2004

Tirade: you're approaching it from the wrong level. The presence or absence of a CMS is irrelevant. Semantics-driven HTML layout isn't immediately beneficial to those who see the web as we do.

People using screen readers, or text-only browsers on hand-held devices will get more out of you developing HTML semantically than people using a 'normal' web browser. Why? Because by developing semantics-rich HTML, your page still makes sense with the presentation layer taken away.

If you want an example of how this works, grab yourself a screen reader, load up your website, close your eyes and try to navigate it. Is the content narrated to you logically? Can you make sense of what's going on?

Otherwise, if you're using firefox, turn off all your visual styles. Does your website still make sense?

That's the point behind using semantically-driven web design. Making sure that your website makes sesne, even to those people who can't 'see' it.
posted by cheaily at 7:44 PM on July 15, 2004

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.
posted by yerfatma at 7:56 PM on July 15, 2004

CSS is perfect.

CSS/XHTML isn't perfect. It's very, very good and I don't want to send it back or anything.

But dagnamit, tables are just *easier* sometimes, and the only thing keeping layout tables from having a valid semanticity in the context of a document is a set of definitions. CSS's designers said "Behold, we don't want a grid or anything that determines which edges of what elements stick to each other and influence each others dimensions" and it was so. But such a thing is immensely useful to have when doing layout, which is exactly why people started and keep appropriating table markup for this purpose.

That said, I think chealiy's comment is worth digesting. Semantic markup makes it easier for software to digest a document, and then do things with it other than regard it as a pretty page. As perhaps the example most quintessential to the modern web, hyperlink would be a significantly less useful thing if it had just been a hotspot people assigned to an area of a page (as it was with early image maps) -- Google would not exist, many clever bookmarklets which pull links out of pages would not exist. When you start to wrap your head around that, you start to really understand document semanticity, and thus get beyond using CSS as just a tool to put pixels in the right place (as helpful as it really is in that regard).
posted by weston at 8:20 PM on July 15, 2004

beyond using CSS as just a tool to put pixels in the right place

But... that's exactly what CSS is for! ;)
posted by cheaily at 8:53 PM on July 15, 2004

Honestly, in most HTML/table based sites with a good CMS, the structure and presentation are already separated

This 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.
posted by adamrice at 8:58 PM on July 15, 2004

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.
posted by 4easypayments at 10:32 PM on July 15, 2004

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.
posted by DrJohnEvans at 5:27 AM on July 16, 2004

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:

1. You can't specify that elements should be adjacent, or otherwise have their properties be dependant on one another.


2. 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.


3. 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.
posted by Khalad at 7:03 AM on July 16, 2004

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.
posted by yerfatma at 7:32 AM on July 16, 2004

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 the literary moose really pushes the envelope for what is do-able with CSS right now.
posted by adamrice at 8:11 AM on July 16, 2004

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.
posted by Khalad at 8:38 AM on July 16, 2004

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.
posted by weston at 9:34 AM on July 16, 2004