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.
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.
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.
: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+bformalism. 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.