Infrequently Noted

Alex Russell on browsers, standards, and the process of progress.

CSS 3: A Giant Serving Of FAIL

In my "Standards Heresy" talk I noted pretty bluntly that CSS 3 is a joke. A sad, sick joke being perpetrated by people who clearly don't build actual web apps. If the preponderance of the working group did, we'd already have useful things like behavioral CSS being turned into recommendations and not turds like CSS namespaces and CSS Print Profile. And I'm not even sure if the "Advanced" Layouts cluster-fsck should be mentioned for the fear that more people might actually look at it. You'd expect an "advanced layouts" module to give us hbox and vbox behaviors or a grid layout model or stretching...but no, the "answer" apparently is ascii art. No, I'm not making this up. It's sad commentary that you can propose this kind of dreck at the W3C and get taken seriously.

Beyond what's obviously wrong with the avenues being (inexplicably) pursued, there's a lot to read into what's not being worked on. Namely the serious and myriad problems with the basics of how CSS rules are written and applied.

Lets start from the bottom: CSS 2 should have included inheritance and variable replacement. It didn't. None of the proposed bits of CSS 3 have their wits about them enough to propose a fix of any kind.

In particular, there's no way for a new, uniquely "named" rule to "mix in" previous rules and tweak them with over-rides to fit a particular scenario. It's also not possible to build a "composite class" out of 2 existing classes. You can either split behaviors into a zillion little classes and then try to ensure that they all get applied to the right elements at the right time, or use fewer (more "semantic") classes which are selector oriented and use selective re-definition to attempt to specialize appropriately. This basic inability to factor out common rules which others may then mix in is, in a word, insane.

There's absolutely no reason why, in 2007, we shouldn't be able to write CSS like this:

.highlight {
color: red;
text-decoration: underline;

.updated { @importRule '.highlight'; background-color: yellow; }

.updatedByOthers { @importRule '.updated'; color: #3f5070; /* a nice dark blue */ }

As for variable replacement, the above example starts to outline why we need it. Writing themes for any non-trivial system via CSS today is a PITA. Here's how it should look:

@define hlColor red;
@define hlBgColor yellow;
@define oUpdateColor #3f5070;

.highlight { color: {hlColor}; text-decoration: underline; }

.updated { @importRule '.highlight'; background-color: {hlBgColor}; }

.updatedByOthers { @importRule '.updated'; color: {oUpdateColor}; /* a nice dark blue */ }

Now, updating this for a new "theme" is as simple as moving the color definitions to an external file and changing the location of an @import URL. All our styles remain in-tact and beyond the initial replacements (and event-driven CSS-OM replacements), the performance impact is slight. That the browser vendors have variously taken it upon themselves to expose parameterized values for things like system colors should have told them something important, but alas no.

The recent growth of CSS frameworks is starting to highlight some of the massive failures of CSS and its implementations, but it's not clear how the web development community is going to shake itself awake and start asking for more than proper ":hover" support from IE. And given the pitiful state of CSS 3, it's not clear that we should even ask the W3C for improvements anyway.

This, I think, is an open and important problem: now that the failure of the W3C is all but complete, what organization (WHAT-WG? something new?) could take on the challenge of, um, challenging the browser vendors to build the stuff we need to keep the Open Web viable? And since we can't reasonably expect IE to support things in a timely fashion, do we owe it to ourselves to start building apps for browsers that will give us what we want?

Update: I'm late to this party (as usual). Andy Budd's thoughts on a "CSS 2.2" are worth a read as is Hixie's dissection of the CSS WG's uselessness. David Baron also responds with constructive suggestions.

The Browser.Next List

Thanks to the Ajaxian's for linking my last post on the topic of what we need from IE. As I've been responding to the comments, it occured to me that it's not quite fair to poke IE in the eye when there are issues (like WYSIWYG) where we need the help of all the browser vendors to get something useful done. That in mind, here's my generic Browser.Next list of 10 issues that would give Ajax libraries a break and let app authors worry less.

It should be noted, first, that these issues are designed to be small, (relatively) easily implemented point solutions to accute problems. They are intentionally not on the scale of "add a new tag for..." some feature or "standardize and implement XBL" or even "make renderers pluggable". While those would all be good, the current pace of browser progress makes me think they're beyond the pale.

This list also tries to avoid vendor-specific issues (of which there are a pile, and many of them may be much more pressing on a per-browser basis than the below issues). Lastly, I'm also not asking for standardization of these things in short order (although it's clearly preferable). We DHTML hackers are hearty folk. We'll take whatever they give us, but we could deliver much, much better developer and end-user experiences if only the browser vendors would all give us:

So that's my list...what's on yours? What am I forgetting? And how should we organize to ask the vendors for these in a way that will really stick?

Older Posts

Newer Posts