Ethan Marcotte now blogs at Unstoppable Robot Ninja.

Weblog entry:

By logical extension

Caveat: I’ve no real idea where I’m going with this, so please feel free to blame Dave Shea if I’m not making any sense. An e-mail of his is what sparked this whole ramble — so it’s, like, you know, his fault. And stuff.

A lot of the teeth-gnashing we do as web designers/developers/[your euphemism here]s these days is surrounding the lack of proper CSS support in the browsers available to us, especially when compared to what the W3 outlines. Spend three minutes tinkering with the SelectORacle or browsing through some of Tom Gilder’s forward-looking posts, and it becomes pretty clear that we’re still not really able to open up CSS on the highway and let ‘er rip.1 So we mutter under our breath about “the separation of style from content” like some sort of coder’s mantra — usually in the same breath that we’re using to curse IE for holding us back from doing so. We dream of the day when we won’t have to use a small army of divs to create a nice drop shadow effect, and dream shiny dreams of super-slim HTML.

But what is it we’re chasing, exactly? Or rather, do we really know what it is we want out of CSS? Semantic web proponents (or, as I like to call them “nutters”) and markup mavens would more than likely embrace the notion of wholly abstracting the presentation layer out of their documents. And I gotta admit, rather than rules that rely on cluttering up your HTML like

div.content p.announcement span.firstletter {
  float: left;
  font-size: 200%;
  font-weight: bold;
  text-transform: uppercase;
}

, using CSS to “hook into” the document’s structure is a much more appealing proposal:

body > div:not(:first-of-type):not(:last-of-type) > h3 + p:first-letter {
  float: left;
  font-size: 200%;
  font-weight: bold;
  text-transform: uppercase;
}

Using the document’s markup as a kind of API for the presentation layer is a pretty appealing prospect. Your markup is truly style-independent, and becomes as a result lighter, more extensible, and so on. But what of the consequences?

As our ability to write more complex rules improves, CSS bloat is the most immediate drawback I can think of; as Dave Shea pointed out, all we’re talking about is offloading the complexity of our markup onto our stylesheets. My primary CSS file is currently about 500 lines long; how long before it becomes 5000?

Another (and more important) potential drawback to better selector support is that the barrier for entry into standards-based design could become much higher. Granted, the second code snippet above is a bit extreme — but I could see a CSS newbie running, not walking, back to his/her nested tables if s/he is unfamiliar with child or adjacent sibling selectors. Hell, if I had to recurse through my document’s element hierarchy to find how a specific rule was being applied, I’d go nuttier than Dave Winer at a RDF workgroup meeting.2

So at the end of all this, I guess the point to my rambling is that while we will eventually have the ability to totally remove presentation logic from our markup, I’m wondering how fully we should. Perhaps the best solution is something in between: where the odd extraneous div and id/class supplements the power of the selectors we’ll have at our disposal.

I’m sure this is the obvious choice, but I had to get this ramble logged somewhere — let me know what you think.

1 Note to self: no metaphors before finishing coffee.

2 Note to self: no jokes before finishing coffee ever again — you’re just not very good at it. And those pants make you look fat. So there.

Comments

Hooray, technical difficulties.

There’s a WordPress issue that’s currently preventing old comments from displaying correctly. Sorry for the inconvenience, but hopefully we’ll be back online soon.