The top 8 web standards myths debunked

This is the first article of a new series with news on the different W3C Working Groups, with a strong focus on the CSS Working Group and associated task forces. I thought that before I start posting news, it would be good to preemptively clear some widespread myths about web standards and explain a bit how the standardisation process works.

Terminology

For brevity and accuracy, the following terms are used in both the present article as well as most standards-related discussions:

Authors: Developers, designers, practically anyone that uses a web technology.

Implementors: Anyone who implements a web technology, usually browser vendors. However, there are other kinds of implementors, for example companies that make developer tools.

Spec editors: People who write specifications. Contrary to popular belief, they do not create the web technologies. You can read more about this below.

Advertisement

1. "The W3C creates standards from up high that browsers have to follow"

Browser innovation vs W3C innovation is a surprisingly widespread false dichotomy. Simply put, the W3C are the implementors! Web standards are developed by consensus in the Working Groups (WGs). These WGs almost exclusively consist of representatives of various implementors, mainly browsers. Each WG has a few W3C staff members, but they are a minority. For example, the CSS WG currently has 74 members, of which only four (5.4 per cent) are W3C staff (Bert Bos, Richard Ishida, Chris Lilley and Liam Quin).

Of course, browsers often innovate on their own and standardise later (eg Drag & Drop API, CSS transitions, CSS transforms, CSS animations) but this is risky and should be avoided. If a feature becomes widespread before standardised, the WG might be forced to settle on subpar syntax.

2. "You have to be working for a big company to influence web standards"

It is indeed much easier to become a Working Group member, if you are working for a member company. The alternative way is becoming an Invited Expert, which is notoriously hard for most WGs. In the CSS WG there are currently four Invited Experts (Molly Holzschlag, Koji Ishii, Brad Kemper and Anton Prowse) out of 74 total members (5.4 per cent).

However, you don't have to be a WG member to contribute. Every WG has a public mailing list, and every good idea is considered, regardless of who it comes from. Usually people who have been following the list for a while may have more concrete proposals, as they are more familiar with the terminology and potential limitations, but neither of the two is necessary for an idea to be considered.

Similarly, bad ideas are rejected, even if they come from WG members. This is very important for keeping the quality of the specifications high, since practically anyone can join a WG. All it takes for a company to be a W3C member, is sufficient funds to pay the yearly fees and anyone from a W3C member company can be a WG member, as long as they have the time and their employer approves it.

3. "Spec editors practically create web technologies"

Not necessarily. There are two approaches the W3C uses:

1. Review, then edit: Every detail is first discussed in the WG, and the editor has to put these decisions into formal writing (to "serialise the group's consensus", as someone skillfully put it). In this model, the editor has as much power as anyone else that's active in the discussions.
2. Edit, then review: The editor has much more power to define a technology and the spec goes through review afterwards.

The CSS WG operates more according to the first model, but that's not true for every WG.

4. "Specifications are primarily written for developers"

Specifications are primarily written for implementors, such as browser vendors. Some editors might make their specs more author-friendly, but that is not mandatory.

5. "Browsers cannot count on standards, because they change under their feet"

In practice, once a specification reaches Candidate Recommendation (CR) status, few significant changes will be made from that point. Earlier stages ("Working Draft" and "Editor's Draft") are work in progress and thus are meant to be changed. Implementations of those are considered experimental and in CSS are even supposed to be prefixed, to avoid conflicts with their future, more stable, counterparts. In the past few years, authors have been relying too much on experimental properties, treating them as stable standards. Therefore, it may seem like standards can't be trusted, but this is not the case. Even when an experimental feature is very widely used on the web, most WGs are hesitant to change it. This is unfortunate since these features are not perfected yet, but unavoidable as doing otherwise would break too many sites.

6. "CSS3 and CSS4 are official terms to refer to CSS versions"

After CSS 2.1, CSS was broken into modules, each with its own versioning. The modules that built on existing CSS 2.1 features were "Level 3" but new features that got developed were supposed to start from "Level 1". Unfortunately, many new modules started from Level 3, further contributing to the popularity of the "CSS3" buzzword. However, many new ones (eg Variables) have started from Level 1, just like they should.

Historically, "CSS3" has been used to mean either everything that came after CSS 2.1 regardless of module level or modules that are explicitly Level 3. Both of these definitions have their problems. If it's used for everything that came after CSS 2.1, how do we make the distinction between CSS3 and CSS4? If it's used for modules that are explicitly level 3, it excludes many new CSS modules for no reason.

7. "W3C test suites exist to test conformance to specifications"

That's a useful function of tests, but from the perspective of advancement toward a W3C Recommendation, tests are there to ensure the implementability of features of the specification. This means that when browsers don't get a feature right, it's not necessarily their fault. It may as well mean that the spec is written poorly, or that the feature is too hard to get right as described or that there isn't enough interest in that feature from implementers to justify including it in that version of the spec. In general, when at least two browsers pass the tests, this means the spec is ready to move on.

8. "W3C = the CSS WG + some small insignificant WGs"

Not at all. When W3C was founded, in 1994 (!), CSS didn't even exist. Many other important web technologies are developed by W3C, either solely or in cooperation with other standards organisations:

• HTML
• DOM API
• Selectors API
• XMLHttpRequest
• XML
• SVG
• MathML
• The PNG file format
• SOAP

and many, many others. The CSS WG is not even the biggest WG. For example, the WebApps WG has 146 members.

Further reading

• A detailed document about W3C processes
• An Inside View of the CSS Working Group at W3C

Many thanks to Doug Schepers, Sylvain Galineau and David Storey for their ideas and feedback.