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.

16 Comments

  1. Posted September 21, 2007 at 6:19 am | Permalink

    I fully agree we need something like “@define”, but I’m not sure about the @importRule stuff.

    Wouldn’t this do the exact same thing and work right now?

    .highlight, .updated, .updatedByOthers {
    color: red;
    text-decoration: underline;
    }

    .updated {
    background-color: yellow;
    }

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

  2. Posted September 21, 2007 at 6:21 am | Permalink

    OMG love it:

    .box {
    width: 100% – 10px;
    }

    Hate this:

    .myInheritedFancyBox{
    @importRule ‘.myfancyBox’;
    background-image[3]: url(anotherImage.jpg);
    }

    Why not use the syntax of other languages that inherit:

    .myInheritedFancyBox extends .myfancyBox
    {
    background-image[3]: url(anotherImage.jpg);
    }

    or:

    .myInheritedFancyBox( .myfancyBox, .myCommentBG, .myFancyBorders)
    {
    background-image[3]: url(anotherImage.jpg);
    }

    the above would inherit from all three classes.

    Anyway, whatever the syntax we need this – please!!

    monk.e.boy

  3. Posted September 21, 2007 at 9:10 am | Permalink

    For what it’s worth, here’s a basic javascript implementation of @importRule:

    http://www.veerwest.com/sandbox/importrule/

  4. Posted September 21, 2007 at 9:26 am | Permalink

    Three comments:

    1) David Baron requested a wiki page to document use cases and ideas about macros etc. That page is here: http://csswg.inkedblade.net/ideas/constants It currently has syntax added by www-style members, but no real use cases. Feel free to add yours.

    2) The Print Profile isn’t targetted at web browsers, it’s targetted at another market that is using CSS, namely the printer implementations. (There are printers whose firmware understands XHTML+CSS; they’re using it for things like templates for photo printing and such.) The Web doesn’t need this profile, but they do, so their WG reps put their time into writing it.

    3) The WG had a discussion about whose job it was to create a CSS Desktop Browser Profile, i.e. a document defining the features that a regular desktop browser is expected to implement and which can be used as a single specification authors can pressure a browser vendor to support. This discussion basically consisted of the two major browser vendors present trying to convince our chair that the WG’s job isn’t to dictate which features are implemented in browsers because that’s more realistically and more effectively done by pressure from web designer community they’re trying to serve. Choosing features for such a profile isn’t something the WG is designed for: we’re designed to write the specifications that define those features. We’re not as well-suited to analyze which ones are needed most by the web authoring community.

  5. bayareacoder
    Posted September 21, 2007 at 11:11 am | Permalink

    For what it’s worth, Håkon Wium Lie talked about these issues in an interview with slashdot last year:

    “Yes, aliases and constants have been considered. As David Wheeler noted, “Any problem in computer science can be solved with another layer of indirection.”

    CSS is already an indirection. Instead of putting properties and values directly on elements, it associates properties and values with selectors. What you (and others) are proposing is to add another layer of indirection. By doing so, one could possible write shorter, more manageable style sheets. However, there are also some downsides. It requires a new syntactic construct (@alias) and implementations must be able to remember a list of aliases. What if aliases are defined in one style sheet and referenced in another — should that work? If so, what if the first style sheet isn’t available?

    For CSS1, the downsides of aliases were considered more significant than the benefits.”

    http://interviews.slashdot.org/article.pl?sid=06/06/23/1443203

  6. Posted September 21, 2007 at 11:50 am | Permalink

    hey bayareacoder:

    Fascinating article! Thanks for passing it on.

    I guess I’m sympathetic to the process by which they were left out early on, but not to continued stalling on adding them. We’ve got a LOT of experience with how these things are used in the real world today, and whatever the pressures on CSS 1 to keep it simple, my view is that these arguments stopped holding water half a decade ago.

    Regards

  7. Posted September 22, 2007 at 8:51 am | Permalink

    I think everyone would agree that CSS constants would be very practical and should be considered in the CSS 3 spec. To simplify the browser’s implementation and avoid ambiguity, I’d say the first constant defined wins. i.e.

    @define myColor red;

    import(blue.css)

    @define myColor blue; (ignored)

    For the @importRule idea, there’s no doubt this would be useful but it makes a lot more sense to use a CSS pre-processor. In my opinion, the benefits are unclear and adds unjustified complexity.

    Last note:
    It would be great to be able to vote somewhere for W3C spec ideas & recommendations.

  8. Posted September 23, 2007 at 6:29 am | Permalink

    I’m completely shocked that there are people who can’t see the obvious benefits of mixins (the import stuff) in CSS. I’m also somewhat surprised that anyone can claim that a complex site can be produced in “30 rules max”.

    I’m sorry, but no matter how good your mastery of the cascade is, nothing more than a simple layout can be achieved in just 30 rules.

    Now, back to supporting the @importRule idea. There’s recently been loads of discussion about the emerging use of CSS frameworks like Blueprint. Mine and many other people’s concern with this framework is that it requires assigning classes to elements specifically for layout purposes leading to much lower maintainability and reduced semantics.

    With an import system you could throw in your framework css, then do things like:

    .article {
    @importRules ‘column span-15 prepend-1’;
    /* other styles */
    }

    Then you don’t need to worry about non-semantic classes in your html because it’s all taken care of in the CSS. You gain all the advantage of the excellent frameworks that are being produced with none of the drawbacks. As it is I’ve been highly tempted to combine use of Blueprint with Moonfall to achieve the same effect.

  9. steve
    Posted September 23, 2007 at 9:28 pm | Permalink

    html should just be lisp. then, lisp macros would solve all these silly issues. stop re-inventing the wheel.

  10. Posted September 25, 2007 at 10:02 am | Permalink

    How do all of these soapboxes fit on one Web page?

    Yes, CSS should be more than it is. Agreed! But if you truly see NO value in the CSS 3.0 Advanced Layout specification then your world must be as narrow as your ideas presented here.

    You disparage and encourage others to disregard entire specifications with tons of good ideas (and a few bad ones). Then you offer us … CONSTANTS?

    The day I can fully divorcing content from layout and banish useless classes like .right, .left, .span-24, .column1, .bottomnav, et al is a day I look forward to.

    Look a little harder and you may be able to see that forest out there past all those trees.

  11. Posted September 25, 2007 at 2:07 pm | Permalink

    I would like to add some more perspective from inside CSSWG. I am one of its newer members (for less than a year), and I perhaps it is my new naïve view but I think CSS working group is very relevant and about as productive as it can be.

    I’ve posted my thoughts here: http://blogs.msdn.com/alexmog/archive/2007/09/25/css-not-moving-blame-microsoft.aspx

  12. Posted September 25, 2007 at 10:23 pm | Permalink

    Wow, a lot more noise than I remember.

    I’ll be frank: define and implement it already! Surely a JavaScript can parse some text and manipulate all of those .style attributes. And if someone ever finally decides to optimize the browsers to what we’re doing, because the documents are right there, we can look around and say “hey”.

  13. Posted October 18, 2007 at 2:56 pm | Permalink

    I would like to say that, at this point in time I am probably more comfortable with all the workarounds I use to achieve the effects that CSS3 claims to do “so easily” that I would rather stick to my workarounds entirely, other things are proving to be more useful than our never coming CSS3 anyway, like DOM scripting in the general sense, even though CSS relies heavily on the DOM.

  14. Posted October 30, 2007 at 8:39 am | Permalink

    I guess this is why I’ve been generating my CSS files programmatically for some time!!

  15. Posted January 18, 2008 at 6:08 am | Permalink

    I guess this is why I’ve been generating my CSS files programmatically for some time!!…

  16. Posted January 18, 2008 at 6:11 am | Permalink

    It would be great to be able to vote somewhere for W3C spec ideas & recommendations.

16 Trackbacks

  1. By CSS 3 and where we could be « outaTiME on September 21, 2007 at 6:32 am

    […] September 21st, 2007 Alex keeps it up by discussing how CSS 3 is a giant serving of fail. Alex believes that in 2007 you should be able to do things like this in CSS: PLAIN TEXT CSS: […]

  2. By Alex Russell’s @importRule - Archive - Veer West LLC on September 21, 2007 at 9:03 am

    […] So Alex Russell (of Dojo fame), not too happy about where CSS3 is going, suggests of a few more important things that should be considered for inclusion in the CSS standard. For instance, an @importRule directive. […]

  3. By Alex Russell’s @importRule - Archive - Veer West LLC on September 21, 2007 at 9:04 am

    […] Several commenters have pointed out that @importRule would not be that useful since you can already assign more than one CSS class to an element. […]

  4. By Iconara » The Failure of CSS on September 21, 2007 at 12:18 pm

    […] By way of Ajaxian I came across a post by Alex Russel on the failure of CSS and how CSS 3 just doesn’t solve any real issues. I can’t tell you how glad I am that for my career as a web developer chose Flash and Flex instead of the Ajax path. One large contributor to that choice was my disappointment that CSS never actually made layout for the web any easier. […]

  5. By MSDN Blog Postings » CSS not moving? Blame Microsoft! on September 25, 2007 at 2:27 pm

    […] Alex Russell’s post of last week questions the lack of inheritance in any of CSS drafts, and overall says “CSS 3 is a joke” […]

  6. By Missing Features » Building a Better Standards Group on September 28, 2007 at 6:49 am

    […] Alex Russell, lead architect of the insanely beautiful Dojo framework correctly points out in a recent post that the CSS3 spec is dead on arrival. Indeed, Alex aptly points out that the W3C has failed its mission wholesale of “Leading the web to it’s full potential…”. […]

  7. By Standardy sieciowe - (x)HTML, CSS i nie tylko... on September 29, 2007 at 4:46 pm

    […] Chodzi mi o świetny artykuł Alexa Russella. Uważa on, iż tak istotne kwestie jak dziedziczenie zapisów i możliwość tworzenia własnych zmiennych powinny być już ujęte w CSS 2. Okazuje się, że w wersji roboczej CSS 3 również tych zagadnień nie znajdziemy – w zamian osoby pracujące nad rozwojem CSS skupiają się na mniej ambitnych celach. Faktem jest, że na chwilę obecną kwestia dziedziczenia jest mocno zaniedbana. Pozostajemy przy dziedziczeniu klas w kodzie HTML, ale co z samym CSS? Przecież często narzuca się, aby zaimportować do jakiejś klasy inną – wcześniej zdefiniowaną o uniwersalnym charakterze. Niestety takiego mieszania klas zrobić się nie da – pozostaje mozolne dopisanie wartości, co niewątpliwie wpływa na puchnięcie całego kodu. […]

  8. […] Introduced by the W3C as a working draft in December 2005, there’s no denying the CSS Advanced Layout module is way better than what we have now, but the apparent lack of interest from browser vendors in implementing this module suggests it might be on the wrong track. Following the release of the latest working draft in August, SitePen’s Alex Russell had some harsh criticism: […]

  9. […] Introduced by the W3C as a working draft in December 2005, there’s no denying the CSS Advanced Layout module is way better than what we have now, but the apparent lack of interest from browser vendors in implementing this module suggests it might be on the wrong track. Following the release of the latest working draft in August, SitePen’s Alex Russell had some harsh criticism: […]

  10. […] We’ve seen both of these voices before, particularly in regards to W3C activities. Some of my previous comments on that topic made the debate louder without (I’m afraid) providing much perspective about how the community can effectively advocate for fixes. What’s good about the ES4 debate (in contrast w/ my CSS ramblings) is that they are scoped to particular implementers. Insofar as advocacy makes a difference, lobbying a working group which is moribund is nearly useless. They have authority but no power. Power in these situations always lies with implementers, aka browser vendors. The CSS discussions are weird and airy because there’s no real skin in the game. Swatting at the W3C is just so much shadow boxing. Asking browser vendors to take risks, to show some good old-fashioned technical leadership and put some of their theories about how to evolve into their competing implementations….now that’s got legs. […]

  11. […] Alex Russell starts a discussion of CSS3 as a failure. […]

  12. By CSS 3: A Giant Serving Of FAIL « turnings on November 14, 2007 at 7:08 am

    […] CSS 3: A Giant Serving Of FAIL 14 11 2007 CSS 3: A Giant Serving Of FAIL: […]

  13. […] But all is not well, nor has it been for a long, long time. No work on hbox or vbox or mixins/inheritance. There’s no indication that the WG has taken stabs exposing the expressive power that Microsoft did with their CSS expressions implementation. Ugg. […]

  14. […] It amuses me that someone who says, CSS 3 is a joke. A sad, sick joke being perpetrated by people who clearly don’t build actual web apps. […]

  15. […] But where the spec is in-front of the important implementations…well, I’ve ranted before on the topic. CSS sucks, and the editor of the spec has now written at length of his intent to keep […]

  16. […] of days regarding how effective (or not) the CSS Working Group has been. I’ve been pretty brutal in my critique in the past (and much of it still stands), but there’s reason to […]