Why (some) standards fail

Disclaimer: I am co-chairman of the CSS Working Group but this article is written with my WG Chair hat off. Personal opinions only.

Jeffrey Zeldman has just released a blog article entitled "Why standards fail", commenting on the now rather old Bert Bos's "What is a good standard?".

In his work, Bert said the W3C specs are not designed for computers but for people. That's right but that's not enough. They're designed for a certain category of people, the code implementors. They're not made for end-users. In other words, a rather complex or long specification like HTML5 or SVG is not made for people authoring HTML5 or SVG, it's designed for people implementing it in a rendering engine, parser, filter, ...

He also says we try to keep specs of reasonable size. Honestly, that dream is really old. Take all W3C specs since 1996 and in particular specs that were updated over the years and you'll see exponential growth.

(As a side note, Bert also said "The Web now runs on HTML, HTTP and URLs". Oh gosh, he forgot JavaScript...)

Jeffrey Zeldman then tells us - in substance - that CSS became a slow monster, that it's not understandable any more if you don't have 5 diplomas in computer science and that browser vendors will move away from complex specs.

Jeffrey forgets too easily a few points here :

  • the work done inside Working Groups is not done by the W3C itself. It's done by vendors and in the case of HTML/CSS/SVG and friends, it's browser vendors. So the W3C Members are very likely to implement the specs, because they designed the specs. The W3C here is just a host, not an author.
  • web designers want more and more features replacing JavaScript and Flash and also want one-liners. First, it's not always possible because a feature itself cannot always be simplified to the point it stands into a very readable one-liner. Second, it's not because it's simple from a design point of view or super-simply implemented in an almost trivial dialog in Photoshop that the code implementation behind is not hellish. And the compromises found in a WG, that please all W3C Members, are sometimes greeted with coldness. Let me take a good example : when I introduced the :nth-child() and friends pseudo-classes in CSS 3 Selectors, we had in the WG a lot of trouble finding the right argument for the function. Tantek pinged his father, who found the an+b formalism. We found it rather nice, meaningful and a good compromise between power and smplicity. Ok, adopted. That said, every time I demo or explain these selectors in a conference, people boo the syntax... So what should we do here ? Increase readability at the risk of complexity ? Drop the feature at the risk of slowing CSS ? As we say in french, it's hard to have the butter and the money for the butter at the same time.
  • we have a lot of documents on the radar because W3C Members don't all have the same strategy, don't address the same market. Opera for instance is big big big on mobile; they want/need things that address their market and don't really care about the rest. On another hand, HP is big big big on printing and things really outside of the print profile are not in their scope. Should we work only on a common denominator or should we consider, as we do know, that all users need to see progress ?
  • at the same time, despite the simplicity of the request, we're still unable to have variables or even constants, we're still unable to position an element relatively to any other arbitrary element in the same tree, we have transformations and gradients only because Dave Hyatt coded it in Safari. The list is long.
  • there a number of good reasons why CSS 2 adoption took so long in browsers. I am not saying it's an excuse for everything but this can partly explain that.
  • perhaps CSS has hit a feature-size limit. Because of their very simple original design, CSS were not meant to solve all the problems of the Web world; we keep hitting issues related to backwards-compatibility, compatible parsing, shorthand compatibility and collisions. Because CSS has grown in circles in a world of RENDERING and not a world of DOM or API, there is a possibility that CSS will not last 50 years (I am negating here a quote from Bert Bos during a CSS WG meeting) and we need a new stylesheet language, still simple from a user's point of view, but more powerful and extensible from a design and implementation point of view. Possibly derivated from CSS. But possibly not CSS itself.

Standards are not only documents. They're not only made for the greatest benefit of Humanity. They're a battlefield. A battlefield where everyone smiles at the other and has a drink with the group after work but a battlefield full of war sagas and full of dead ideas and codes. Dead companies too. Such a situation does not always end up in good compromises. Some compromises are weak, some are even dangerous. Some are bloody.

So yes, SOME standards fail. Because standards are made by human beings, because human beings can make mistakes and because human beings - standards authors and users - are the most painful species on this planet, rarely happy with what they have in hands.

Yes, the CSS 3 specs are big. And complex. No it's not really a problem because fortunately cool guys like Jeffrey Zeldman cover the world giving conferences about CSS, because Eric Meyer next CSS 3 book will be here to explain CSS to the masses. That's not the W3C's job. And yes, CSS 3 is going to be implemented because the specs come from the browser vendors anyway. And yes, CSS 3 is going to used by web authors. Probably not the deepest complex bits of CSS 3 like "floating and spanning rtl klingon in paginated top-to-bottom uighur" but I am pretty sure that all CSS 3 features will be adopted by the community as soon as they are implemented.


1. On Friday 24 July 2009, 18:00 by Yann Hamon

Hello Daniel, one of the reasons I see as a potential failure is the time between versions of CSS and HTML. While the web has evolved a lot in the last ten years, HTML4 has been released in 1999, and CSS2 in 1998! You may argue that it took time for browser vendors to fully implement them and you're right; but with the browser competition starting again we may hope that these times are over.

So, what do we see:
* Browser vendors are already implementing and pushing <video> and <audio> although they are part of HTML5 which is only a draft - it means they are so important that they do not think it would wait for the final release of html5...

* Every vendor has his own implementations of CSS3 properties... --moz-border-radius, --webkit-border-radius : same story here

One of the things these show: it seems extremely hard to publish full versions of CSS and HTML as every vendor is pushing in a different direction, as you explain. However, there are some elements that seem to create consensus, as they get implemented in nearly every browser.

Maybe what I suggest doesn't make sense at all, as I am not really familiar with the w3c processes but:

Would it be possible to release CSS and HTML, bit by bit? Agree on a new HTML tag and validate it for use, agree on a new CSS property and validate it for use? Instead of trying to please every company and failing to release completely, or with tremendous delays?

It wouldn't change much in the developer world, as we have to deal with inegally implemented specs anyway. And we could get very important features on which there is consensus earlier.

What's your view on video? All browsers started to implement it, websites like wikipedia, google and dailymotion started using it, but all in all: it's still part of the HTML5 draft?

2. On Friday 24 July 2009, 18:42 by Eric

I am not sure to agree with your first point Daniel. A spec on a format is both for the one who produce the file (authors) and for the one who consume it (browsers) because both have to know about it and use it. I will even tell that the end purpose of having a spec at all is to allow a better communication between the authors and the end users. Browsers are only a tool between both of them.

There is no point in having a spec that is only for consumer softwares. If you expect a specific format, producer need to also use the same format, with the same rules, and for that to read the same spec. Not all part of the spec is usefull for web producer but the opposite is also true : not all part of the spec are necessary for browser implementation (or should be necessary, if you find only browser related documentation in the spec, that is a problem).

Thinking that web authors may only use second level documentation, some kind of popularization of the spec seems somewhat like considering producers as children or low level/importance characters and browser's developpers as the "only real developpers / VIP". I strongly disagree with a such classification and judgment. There are real experts and skill-less developpers in both side (yes, maybe not in Mozilla / Microsoft / Opera / Webkit, but these 4 are not the only players).

I am not saying that the W3C should focus only on web authors, or that it should implement all thay could ask (please don't), but if a spec is too complex for web author experts to understand/use, then it is a real problem. Please don't discard it thinking that end user popularization ot it will do the trick.

"it's designed for people implementing it in a rendering engine, parser, filter, ...". Exactly my problem you miss the producer engines, editors and such. I don't blame anyone, maybe we only miss web authors peoples in the working groups. Amazon and Yahoo! (and many others) should probably join to participate. They don't (as far as I know), and that is a shame.

3. On Friday 24 July 2009, 19:33 by Yann Hamon

Giving a few more thoughts to my earlier proposition :)

It could be possible to add these additional tags/properties by grouping them in "modules"/ components, and release separated specs.

It could be good for advertising "Now compatible HTML Forms 8" "Includes full support for HTML Multimedia 1.0", "Canvas Ready".
The browsers wouldn't probably implement all of them at the same time, but now, no browsers implement completely the specs neither...

This could make compliance easier (you would be compliant with 60% of the modules, instead of being 60% compliant with the global spec) - and tests like acid3 could be targeted at specific parts, making them easier targets.

4. On Friday 24 July 2009, 22:06 by niemand

Regarding the --moz-border-radius, --webkit-border-radius, which are implementation of the standart to come, wouldn't it be possible for browsers vendors to use something like --css3-border-radius or --whateverincommon-border-radius?

5. On Saturday 25 July 2009, 08:39 by Vladimir Dzhuvinov

I'm pretty much satisfied with what CSS offers. So my thanks to everyone on the WG for their effort.


You can't really have a super simple standard when you address issues of some complexity. And styling web pages isn't that trivial, actually. So don't worry too much about that.

6. On Saturday 25 July 2009, 11:57 by Jeff Walden

Regarding the first bullet, I know someone I consider pretty smart who thinks that the W3C sees itself as providing technical expertise to working groups, but the working groups themselves see the W3C as merely providing a forum and infrastructure for a meeting of the minds in their work. He (specifically as a gender-neutral pronoun, not a masculine one) thinks this disconnect plays a large role in the lessening relevance of the W3C to the improvement of the web and of web standards. (I would name the person if I knew I had permission to do so, but I don't. Feel free to guess if you want; you might even be right.)

7. On Thursday 30 July 2009, 23:29 by Bronislav Klučka

The problem with W3C is that it has become gravedigger of web technologies.
Go back to 90's you can see extremly fast progress. An why? Because it was vendors and only wendors who presented new technologies and when successfull those technologies was adopted by competition (MSIE copying from NN and vice versa).

The late 90's was the time to standartize all technologies. And that was a good thing from W3C to do that. But W3C should remailn a group of people/companies selecting core of technologies and giving them one and only one meaining and behaviour. But not, this (commersional) group of people decide to 'lead web' and that was the dawn of current problems.

Look at new millenium, there is no usefull web technology specification. Why? Because everybody is waiting for this 'great leader' to finish one. Imagine W3C is not inventing, I guess there would be a lot of new technologiesa, changes in existing one, presented by vendors, coopted by other vendors if successfull or forgotten. The web technologies would grow. Not stagnate.

Do not forget, it were NN and MSIE who literally created HTML 4, this specification was made according to current capabilities, it NN who presented JavaScript, MSIE presenting XmlHttpRequest, Mosaic presented tables, Netscape presented frames, etc.

What are W3C "accomplishments"? 1/ NN presented border box model, W3C CSS defined content box model (although NN and MSIE had more than 90% of penetration), Why?
2/ MSIE 4 presented 'cursor' property with 'hand' value, W3C presented 'pointer' value. Why?
3/ MSIE 4 presented button element, W3C changed its behaviour. Why?
4/ NN presented 'embed' element. W3C presented 'object', for the same purposes. Why?
5/ MSIE 4 presented 'messagebox', 'smallcaption' and 'statusbar' values for 'font' property, W3C chaged them to 'message-box', 'small-caption' and 'status-bar'. Why?

Any other W3C "accomplishments"?
1/ creating virtually pointless XHTML 1 (there are no benefits against HTML)
2/ creating XHTML 2, never used

The only good thing done W3C sice 90's is incorporating VENDORS' specifications (known as HTML5)

Instead of a decade of waiting for CSS3 (still far from finishing), W3C shoud create appedixes to existing CSS 2.1. Imagine Appendix 1 - roud borders; Appendix 2 - columns; Appendix 3 - variables and consatnts;
There could be a lot more CSS capabilities (alredy implemented capabilities).

W3C had become like self-assure Church thinking how is is "leading teh Web to its full potential" not seeing it's actually standing in the way.

Bronislav Klucka

8. On Friday 31 July 2009, 09:22 by Daniel Glazman

@Bronislav Klučka: answers to your questions above:


1. because bith MS and NSCP agreed on that as Members of the W3C. A spec is a compromise between the various proposals on the table.

2. because in some cultures, a hand or a finger displayed as we westerners see it onscreen is an insult

3. see answer 1 above

4. because object was not enough and we could not reuse the same name

5. to be coherent with all other system-based names that dashed the names

"other accomplishments":

1. there are benefits ; sorry if you can't see them

2. we agree on that one


- CSS 2.1 does not exist yet ; it's not a REC yet.

9. On Thursday 6 August 2009, 21:16 by Bronislav Klucka

@Daniel Glazman: answer to your answers
1/ I do not want to accuse you of anythink and I hate conspiration teories, but compromise is not agreement. I'd like to see how MS and NSCP could actualy agree with box model those companies have already implemented.

2/ ok, valid point

3/ see answer 1 abowe

4/ your answer doesn't make sense... W3C created 'object' element and you're writing that 'object' was not enought..

5/ I've just checked property table of css2.1 and there are no other system-based values

The benefits are non existing, the results are decade of web designers misery (Caused not by MS neglecting reccomendations, but by reccomendations ignoring existing behaviours)

The benefits of XHTML over HTML? There is only one difference: XHTML is implemetation of XML based on HTML semantic. There is no other difference.
The only benefit 'could' be the extensability of XML using namespaces, but there are only 2 attempts having 'some' success: MathML and SVG, but widely unused and actually not mised.

Claims that XHTML does not allow tag soup as HTML, that the code is more stuctured than HTML, easily parsed than HTML are just marketing lies (not inaccuracies, actual lies).

OK, CSS 2.1 is just draft, my point in that sentence is elsewhere.

Do not get me wrong. W3C did a great job, but looking at the core web technologies (X)HTML and CSS the progress of quality, quantity and reasoning is terrifying.

Bronislav Klucka