Infrequently Noted

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

Comments for CSS 3: A Giant Serving Of FAIL

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.

by Stevie D at
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.


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.

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

by Mark at
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!

by she at
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.
by Rudd-O at
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.

by MilesZS at
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.
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.
by Truckee Roads at
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.
by Andrew Steele at
I guess this is why I've been generating my CSS files programmatically for some time!
by Dave at
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';

by Drew Vogel at
Stupid blog doesn't escape my HTML for me? blech! Would have been solved with a preview button.
by Drew Vogel at
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

Toggling a class on body would change entire theme.

by Alex G at
All this can be accomplished with

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.

by Kevin at

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


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.

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.

by dgurba at
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?

by Al Vazquez at
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.

Another thing I would love to see is something like:

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

by Ratty at
Write a CSS pre-processor to handle stuff like this.
by brian at
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).


by Karl at
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.
by Vagary Jubin at
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?
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:

.myInheritedFancyBox{ @importRule '.myfancyBox'; background-image[3]: anotherImage.jpg; }

by Anders at
Little fix:

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

sorry :P

by Anders at
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.

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.


by alex at
I'm glad someone else had the same idea:

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

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.


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)

by Johnny Plotette at
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.

I posted a response at .


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


by alex at
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.
by Dan Kelley at
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?

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?

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 for details. But this is less about what should be implemented than about what is ready to be implemented.


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.


by alex at
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.
by Chris B at
@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.

Sincerely, Joe

by Joe at
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.


by Alan G at
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.

Regards, Francesco

by kama at
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.
by Nat at
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!

Actually, the grid layout proposal is pretty nice:

"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.
by TC at
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 */ }

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


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


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

by cedric at
Three comments:
  1. David Baron requested a wiki page to document use cases and ideas about macros etc. That page is here: 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.

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

by bayareacoder at
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.


by alex at
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.

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.

html should just be lisp. then, lisp macros would solve all these silly issues. stop re-inventing the wheel.
by steve at
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.

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:

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

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.
I guess this is why I’ve been generating my CSS files programmatically for some time!!
I guess this is why I’ve been generating my CSS files programmatically for some time!!...
It would be great to be able to vote somewhere for W3C spec ideas & recommendations.