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.


  1. Stevie D
    Posted September 20, 2007 at 5:24 am | Permalink

    That is a great idea … why isn’t it happening? Even as someone who doesn’t use anywhere near the full potential of CSS, I would love to be able to create rules that ran across a site but changed the colour of elements on different pages. Doing that now is a heck of a lot of work, but what you’re suggesting would make it easy as pie.

    I do quite like the ASCII-art model of laying out the page, that you’re so critical of. No, it’s not perfect, and I would certainly hope to see a more technical alternative, but as a way to help newbugs buy into CSS and get into using CSS for layout instead of tables.

    While we want to raise the bar as far as browser support and CSS standards go, we also need to remember to lower the barrier to entry – CSS needs to be easy to use, or else we won’t keep converting people to it, and the tables will be perpetuated.

  2. Posted September 20, 2007 at 5:29 am | Permalink

    Right on, Brother! But it seems like the only way to make the web move forward is to influence the browser vendors somehow. Perhaps a FF extension or IE plugin could implement some of this? It’s a tough row to hoe.


  3. Posted September 20, 2007 at 5:54 am | Permalink

    CSS1 was revolutionary, CSS2 was really CSS1.5 as designed by retards, and CSS3 is CSS0.5 alpha pre5 as designed by marketing research retards. The same retards who are working on HTML5, mind you.

    @define is an element I have longed for since the very early days of CSS. And @importRule could also be expressed:

    .one { /* design */ }
    .two with .one { /* design */ }

    (or replace “with”… with “from”, “extends”, “includes”)

    That would fit more into the basic setup of CSS in general (ie, wouldn’t break the decade of learned CSS behavior). And would make relating it a little easier for OO programmers. Also, it would be a lot better than expressing multiple classes and ids inline (which is pretty dumb, if you ask me).

    I know there are people who will vehemently claim up and down that HTML/CSS aren’t programming languages, suitable for stupid people and monkies. And they are right, in the barest technical sense. However, when it takes the the learned thinking process of (other) programming languages to do anything relatively decent with HTML/CSS you can’t say they really aren’t programming languages by saying they are not dynamic. Punch card programs weren’t dynamic either.

  4. Posted September 20, 2007 at 6:19 am | Permalink

    This post outlines some of my most wanted CSS features that would solve constant headaches. I haven’t really been following the CSS 3 plans, but to know that this stuff isn’t a part of them saddens me.

  5. Mark
    Posted September 20, 2007 at 6:33 am | Permalink

    IMO, CSS namespaces would be useful. Print Profile probably too.

    Inheritance and Variable replacement is nice too, but can easily be solved by using some preprocessing tool (xslt, if nothing else).

  6. she
    Posted September 20, 2007 at 6:55 am | Permalink

    Well some valid points there but i must tell you I HATE HATE HATE THE SYNTAX you use here.

    CSS so far was EASY and simple to use, these new intros with that vars just make things more and more complex with only little gain.

    Sorry, not convinced about this!

  7. Posted September 20, 2007 at 7:00 am | Permalink

    Excuse me, but what’s wrong with declaring three separate classes, then specifying in the tag the three classes as class=”highlight updated updatedByOthers”? This would give you exactly the same result without any confusion.

  8. MilesZS
    Posted September 20, 2007 at 7:02 am | Permalink

    As with Mr. Messier, above, the things you outlined are features that I have always thought seemed like the next natural progression for CSS. I, too, am guilty of not following where CSS is being pushed. Aren’t the things you mentioned obvious to others who work with CSS often?

    Would it be advantageous to push these types of changes to CSS into open source browsers, with the possibility that the closed source browsers may follow? … maybe I’m just too optimistic, and at least mildly naive.

  9. Posted September 20, 2007 at 7:06 am | Permalink

    I must say as a fellow csser for the past 7 years, any movement in the right direction would be beneficial. You read in the IE 7 blog about this new commitment to standards as well as css2 and 3 support, but good luck to that. And I hate to say it but I really feel the W3C has their own agenda, with these dumb ass decisions they make.

  10. Truckee Roads
    Posted September 20, 2007 at 7:08 am | Permalink

    Great article. I have tried many solutions to the “variable” issue. Your proposal is clean and functional, which only serves to ensure we’ll never see it implemented. Keep up the good work.

  11. Andrew Steele
    Posted September 20, 2007 at 7:35 am | Permalink

    As an intermediate CSS developer who mostly works as a BLL developer I cannot tell you how much of a difference the above outlined changes to CSS would make. Suddenly, CSS development would become a lot more obvious rather than the crap shoot it can become when you have a glut of rules to define every situation. The only way I’ve found my way through it is with the Web Developer toolbar add in. The ability to point to element and get all of the CSS applied to that element is invaluable.

  12. Dave
    Posted September 20, 2007 at 7:35 am | Permalink

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

  13. Drew Vogel
    Posted September 20, 2007 at 7:39 am | Permalink

    Inheritance is achieved by assigning multiple CSS classes to an element.

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

    .updated {
    background-color: yellow;

    This would achieve the same effect as your @importRule ‘.highlight’;

  14. Drew Vogel
    Posted September 20, 2007 at 7:41 am | Permalink

    Stupid blog doesn’t escape my HTML for me? blech! Would have been solved with a preview button.

  15. Posted September 20, 2007 at 7:48 am | Permalink

    I very much agree on the need of better layout spec, however…

    The composite classes are very much possible, just not within definition but in the actual HTML. Your example of ‘updatedByOthers’ in current implementation would look quite simply like `div class=”highlight updated updatedByOthers”`

    CSS variables are nice, but it’s very easily achieved with dynamic CSS. Setting up CSS themes is ridiculously easy:

    body.redtheme .panel { background: red; }
    body.bluetheme .panel { background: blue; }

    Toggling a class on `body` would change entire theme.

  16. Kevin
    Posted September 20, 2007 at 7:52 am | Permalink

    All this can be accomplished with http://moonfall.org

    Yes its “wrong”, its a hack, but its easy to use and it does implement variables and what you described as @importRule ‘.highlight’;

    Its sad that this is needed. I don’t know what is wrong with them.

  17. Posted September 20, 2007 at 8:24 am | Permalink


    Some at last talking sense !!! Variables please !!


  18. Posted September 20, 2007 at 8:25 am | Permalink

    CSS 3 won’t fix the problem because standards are never standard. It didn’t work with CSS2 or 1, or with html or xhtml or strict/transitional doctypes, etc. It’s because there is no one good way to do things, yet *there should be* especially when dealing with software.

    But even if there were ‘one good way’, Microsoft would muck it up by doing something different anyway. Because they are retarded, and by retarded I mean ‘they can get away with *anything*’. (Thanks for that Sara Silverman.)

    When one builds a website, one has to bring the knowledge of not only a bevy of standards (html/javascript/css/xml- i could go on for days), but also browser quirks. Each browser has a differential support for standards, which breaks the notion of a ‘standard’. It can take twice as long or longer to learn browsers’ implementation quirks than to learn the standards themselves. Since technologies are multiplying, it’s becoming exponentially more difficult to be a ‘flexible developer’ for different clients because you have to know exponentially more ‘quirks’.

    This is a big reason why I’ve chosen to leave the field of IT and web development forever. It’s too annoyingly and needlessly complex. Have fun with CSS 3.0. It will make matters worse and won’t offer anything new or better.

  19. Posted September 20, 2007 at 8:30 am | Permalink

    from wikipedia: In web development, Cascading Style Sheets (CSS) is a stylesheet language used to describe the presentation of a document written in a markup language.

    You can do what you want (declares/imports) … Companies I have been with use php to declare ‘variable’ values all the time, eg.

    .headline {
    color = ;

    granted, this isn’t CSS … and this isn’t the cleanest way to do things (global variables, icky).

    But maybe there should be a way css itself could do the programming/logic stuff and leave it to the browser to interpret it all.

  20. Al Vazquez
    Posted September 20, 2007 at 8:33 am | Permalink

    It seems like the only reason a standards body is effective is if it’s relevant. Clearly, the W3C is quickly losing it’s relevancy relative to CSS. If WHAT-WG or another organization could get enough mind-share to be RELEVANT to the web design community, it wouldn’t be too difficult to get the “lesser” browser makers to work closely with the new standards that body produced. From there, competition in the browser, would, one way or another, force some of the new features to be adopted.

    How can we, with stake in this space, get the ball rolling?

  21. Posted September 20, 2007 at 8:35 am | Permalink

    That has got to be the most ludicrous “proposed standard” ever seen that wasn’t an April 1st RFC. Actually, some of those have been implemented… I pray this never is.

    For anyone who gets stuck at all the a priori’s and doesn’t get to the ascii art, just scroll down to the examples.

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

    Another thing I would love to see is something like:

    .box {
    width: 100% – 10px;

  23. brian
    Posted September 20, 2007 at 9:08 am | Permalink

    Write a CSS pre-processor to handle stuff like this.

  24. Posted September 20, 2007 at 9:29 am | Permalink

    Ugh, my comment got lost… :(

    As I tried to say the first time, why dont we strike up a converstation with the FF devs, it could be a very small hack to get what we want. They seem to be very much on board with making the web better.

    Personally, it would be great to see a plugable CSS engine, so FF can continue to support the [sub]standard created by w3c, but also support what we all have been clamoring for… This would keep the browser “compliant”, but allow us to continue pushing the envelope with the web by turning on a simple pluggin. (support the standard, yet drive innovation?)

    As for building for browsers that can’t/won’t do what we need, I agree. Why coddle software companies that won’t listen, won’t standardise, and won’t work with *US* the developers? Back in the not so old days, if you had a lame horse, it was put down…. Some companies need to take some lessons from the past, and just move on (because they certainly aren’t keeping up).


  25. Vagary Jubin
    Posted September 20, 2007 at 9:48 am | Permalink

    Does anyone really care about the usability of a meta language on top of a broken core? Having to write that code in the first place is obscene.

  26. Posted September 20, 2007 at 10:12 am | Permalink

    Good post. I like your mixin idea. You missed CSS 1-2’s greatest omission, however: vertical alignment of block level elements. Does the CSS3 draft say anything about that?

  27. Anders
    Posted September 20, 2007 at 10:13 am | Permalink

    The CSS3 standard also only specifies one way to define multiple background images by listing them all one one line after each other.
    This makes lots of problems for those who want to overwrite the third background image defined. Those people would have to redefine all background images for that paticular element and doesn’t really help inheritance either.

    I would suggest a way to access a given background image with an index:

    @importRule ‘.myfancyBox’;
    background-image[3]: anotherImage.jpg;

  28. Anders
    Posted September 20, 2007 at 10:13 am | Permalink

    Little fix:

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

    sorry :P

  29. Posted September 20, 2007 at 10:14 am | Permalink

    I’d love to see these features included in a new version of CSS. They’d make my life a lot easier too.

    The Advanced Layout module of CSS 3 in particular looks like it will be a nightmare. And totally useless for any practical purposes. Especially since the chance of it being supported in any widely-used browser is minimal at best.

  30. Posted September 20, 2007 at 10:42 am | Permalink

    Ratty: I decided to leave my musings about parametric replacement out of this post, but clearly it’s the next step. In fact, you need to be able to specify things using an expression that makes it relative to other (computed) values from the layout. Without that, what you propose is good but probably not enough.

    AlexG, Drew: I hope you don’t imagine me so daft as to have missed what you’re pointing out. In fact, I addressed it directly in the post. What grates isn’t that you can’t use multiple classes to set this kind of thing up at the node level (obviously you can, and in Dojo we do it to a degree which is slightly nauseating), it’s that it scales like shit. It just doesn’t work well when you’ve got hundreds of rules and would like to express small relationships between them. Being able to do something in a tortured, expensive way and being able to do it naturally is in many kinds of technology the difference between success and failure.


  31. Posted September 20, 2007 at 10:42 am | Permalink

    I’m glad someone else had the same idea: http://www.nczonline.net/archive/2007/1/416

    I have no idea why variables haven’t been introduced already. Ridiculous.

  32. Posted September 20, 2007 at 10:48 am | Permalink

    This is the first time I’ve seen Moonfall, but if it’s “wrong” so is this and every other web site that uses server-side scripts to dynamically generate HTML. (However, I agree with #7 and #15, and have no use for a CSS generator / preprocessor.)

    Behavioral CSS sounds like an oxymoron to me. Behavior already covered by the script tag and the DOM.


  33. Johnny Plotette
    Posted September 20, 2007 at 10:53 am | Permalink

    I really hope IE, Opera and Konqueror will *not* implement CSS3, and thus the standard will die.

    The web was about network-aware text documents wih minimal presentation quirks. But CSS+HTML+DOM+Javascript is just too much.

    If they want more they can propose an open-standard implementation of something like SWF. Vector graphics, interactivity, etc. It’ll be much simpler than the entire stack of CSS3/Javascript3/HTML5, smaller and with tons of more features. (But these plonkers at WHATWG would probably use XML anyway! Screw that. SWF is better than SVG exactly because it doesn’t use XML madness)

  34. Posted September 20, 2007 at 11:41 am | Permalink

    Several years ago I helped create a CSS pre-processor written in Python called Switch. I haven’t touched the SourceForge page in a while so the code is out-of-date, but if you look over the included documentation you’ll see it’s implemented your suggestions and several others.


    If there is interest, I can post a more up-to-date version on SourceForge that includes caching and speed increases.

    I had never heard of moonfall before, sounds promising.

  35. Posted September 20, 2007 at 1:01 pm | Permalink

    I posted a response at http://dbaron.org/log/2007-09#e20070920a .


  36. Posted September 20, 2007 at 1:45 pm | Permalink

    Hey David:

    (responding here because your blog doesn’t appear to have a comment feature)

    Thanks for taking the time to respond. Your efforts to get the CSS WG to do its work in public is much appreciated and I sincerely hope that the WG continues to make more of its deliberations open. Publishing things on the TR page wouldn’t be so bad if there were any way to draw any particular item or feature back to the discussion(s) which spawned it. That the deliberations themselves cannot be examined may contribute to the artificial sense of credibility that you note.

    I will note, however, that I feel the breakup of CSS 3 into separate “modules” without any visible means of punishing vendors for not implementing all Recommendation level specs accurately and in a timely fashion is a huge mistake. Breaking up the spec thusly will, inevitably, lead to more of the fumbling around in the dark that webdevs are used to as we attempt to figure out what works (where “works”==”works everywhere”), what sorta works, and what doesn’t. Instead of putting the pressure on the browser vendors to duke it out at the negotiating table and making them really fight for features and prioritization, the working group took the lazy way out. There’s now no enforcement, no back-pressure, and no clarity about what we “should” have. The WG has utterly and completely failed the webdev community while managing to soothe and keep the “peace” amongst vendors. It’s a disgusting abdication of the WG’s responsibilities and purpose.

    Lastly, I was tentative about proposing this as CSS syntax, and I expected more folks to point out that the outlined @importRule and @declare are entirely ambiguous. That they haven’t, I think, speaks to the reason I went ahead with it anyway: until we have some visible, tangible examples of what the world should look like, our current situation doesn’t look shabby enough to beat the coeficient of static friction that prevents change. On balance I think it was worth it…it got you to reply thoughtfully ;-)

    As for next steps, I don’t have the temperament for standards body work (just ask Brendan), but I’d happily provide comment and work with you on an initial draft of something more concrete.

    Thanks again for taking the time to respond.


  37. Dan Kelley
    Posted September 20, 2007 at 3:06 pm | Permalink

    Pipe dream: people on forums such as this invent a better CSS, then FireFox developers adopt it, leaving the formal CSS committees. Then let IE conform to the de facto FireFox conventions.

  38. Posted September 20, 2007 at 3:52 pm | Permalink

    HTML had a laudable goal of making layout independent of the size of type. Something that was necessary back in the 90s when HTML was mostly text. On top of it, it meant that HTML could be rendered differently depending on form factors, like PDAs and cell phones.

    However, server side generation of pages meant that this is no longer necessary. Reading NYTimes from a PDA? avantgo.com

    In fact, iPhone has gone so far as to render in fixed layout mode, and let users zoom in on the content.

    Time for all to head for absolute layout instead?

  39. Posted September 20, 2007 at 4:12 pm | Permalink

    You can’t punish browser vendors for not implementing things that are W3C Recommendations. That hasn’t made sense for almost 10 years. Have you seen the list of things that are recommendations? It makes a lot more sense to ask browser vendors to implement the things that are useful to authors and users. (That doesn’t mean every author gets every wish.)

    Furthermore, I don’t think the CSS working group is necessarily the best place to decide what browser vendors should implement — it essentially becomes a case of browser vendors putting pressure on each other. I think more author feedback in determining the list of what should be implemented would be better.

    That said, the CSS WG is planning to publish a series of “state of all of CSS” documents. See http://lists.w3.org/Archives/Public/www-style/2007Sep/0097 for details. But this is less about what should be implemented than about what is ready to be implemented.

  40. Posted September 20, 2007 at 4:48 pm | Permalink


    So I’m not suggesting that we necessarily punish browser vendors for not implementing everything. You’re right that the W3C ratifies a lot of crap that no one needs. What I’m suggesting, though, is that there are some specs that are clearly (to use the CSS WG’s terminology) “High Priority”. These things (HTML, CSS, DOM) really can’t be left to chance, and that’s what the WG’s new structure effectively does. We’re facing the atomization of the second most important web spec and the organization whose job it is to force agreement isn’t doing that. I’m only suggesting some sort of conformance “gold star” (carrot) or sanction (stick) now that it’s almost incomprehensible as to what CSS 3 will “be” and at what level the various vendors will ship them (and when). In a world where CSS came in one bundle, this was pretty obvious: just organize a large enough raiding party and camp out in front of the steps in Redmond or Mt. View or wherever is required. Now that things are atomized, it’s that much harder to get a constituency together. Maybe the list the WG is going to put together can be that “thing”, but I doubt it.

    As for where features should come from, I think we’re in 100% agreement that the WG isn’t the place to propose brand new stuff. Browser vendors need to listen to their users and implement things ahead of the specs. Once something is in the wild and is generally deemed to be useful and/or good, then standardization makes sense (and browser vendors putting pressure on each other is good and justified at that point). The CSS WG’s most glaring failures seem to be around where the WG is “leading” what’s shipping or are ignoring what browsers are shipping.


  41. Posted September 20, 2007 at 7:47 pm | Permalink

    The main concern is an easy to understand and use grid layout. It really bugs me that no solid ground has been made. What has been recommended so far is terrible. It should be compulsory for the people devising CSS3 to build a few fully fledged websites, rather than a few quick colour box layout test cases.

  42. Joe
    Posted September 20, 2007 at 10:08 pm | Permalink

    @The Author:

    You have worked in sites with “hundreds” of rules that you have had to juggle? SERIOUSLY? I don’t believe that for a second. If it takes that many rules, then you aren’t using CSS correctly. You just aren’t. What you are doing, it’s called over engineering.

    Trying to treat CSS like a programming language is LAME. CSS is meant to be simple. Simple.


  43. Alan G
    Posted September 21, 2007 at 1:15 am | Permalink

    Nice work.

    Lack of variable substitution is my #1 grumble with CSS (cf. DRY principle) – this can only make life simpler, more readable and more consistent.

    Inheritance sounds useful, and if you don’t want to complicate your CSS with those rules, you can stay with the basic CSS.

    It would be nice to have some accepted way of handling browser differences, since we all know they exist and will do for a while.
    Akin to Javascript techniques, checking for existence of object/capability, rather than the clever but nasty hacks that I seem to be forced to include occasionally.


  44. Posted September 21, 2007 at 3:22 am | Permalink

    Good points, but I agree with the last comment from Joe. CSS is great because it’s simple and easy to use. Even in a site with 1000+ pages, if you organize it well, you can end up writing 30 rules max.

    You don’t need @importRule as you can apply multiple classes to the same HTML element.


  45. Nat
    Posted September 21, 2007 at 4:46 am | Permalink

    What you want with variables, imports, inheritance, etc. can easily be achieved using existing tools as a preprocessing step during the website build. CSS works well as a data format but web developers don’t work directly on the files that are actually published (at least good ones don’t). Final published artefacts are generated automatically from source artefacts as part of the publishing pipeline.

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

    I agree that ASCII art is pathetic. How come I can create a hexaginal div and rotate it 7.3 degrees and fill it with a cool font and add drop shadows and stuff?

    W3C must be a bunch of old farts who’ve never seen a Playstation. I mean COME ON OLD FARTS I want to make a cool Tony Hawks style menu system?

    HTML + CSS = turd. Just take a look at flash and silverlight. Lets just make the web copy them.

    Static text at 90 degrees + static pictures = printed pages. I want the INTERNET – NOW!

  47. Posted September 21, 2007 at 5:24 am | Permalink

    Actually, the grid layout proposal is pretty nice:


  48. TC
    Posted September 21, 2007 at 5:25 am | Permalink

    “Dots” distinguishing user defined elements from native ones? The whole syntax was fsked from the start. It’s like it was designed by hopeless amateurs.

  49. 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 */

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

    OMG love it:

    .box {
    width: 100% – 10px;

    Hate this:

    @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);


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


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

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


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

  53. 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.”


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


  55. 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;


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

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

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

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

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

  60. 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”.

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

  62. 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!!

  63. 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!!…

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

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

18 Trackbacks

  1. By soeren says » Blog Archive » More CSS 3 musings on September 20, 2007 at 10:21 am

    […] Via reddit: “CSS 3: A Giant Serving Of FAIL” […]

  2. […] are worth a read as is Hixie’s dissection of the CSS WG’s uselessness. David Baron also responds with constructive suggestions.   if(!mmposts){var mmposts=[];}mmposts[mmposts.length]=”625″; […]

  3. 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: […]

  4. 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. […]

  5. 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. […]

  6. 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. […]

  7. 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” […]

  8. 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…”. […]

  9. 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. […]

  10. […] 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: […]

  11. […] 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: […]

  12. […] 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. […]

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

  14. 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: […]

  15. […] 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. […]

  16. […] 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. […]

  17. […] 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 […]

  18. […] 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 […]