Establishing Web Standards

Aaron Gustafson explains how an idea becomes a specification at the World Wide Web Consortium (W3C)

When we’re busy building stuff for the web, we don’t get much time to ponder how the HTML tags we write and CSS properties we use come to be. I’m here to shed a little light on the way our standards become standards.

First off, the ‘standards’ created by the W3C aren’t really standards, but are rather a collection of specifications that instruct browsers on how to implement certain language features, so when we use a certain HTML element, browsers display it in pretty much the same way. The term ‘standards’ isn’t used by the W3C; what we think of as ‘standards’ are actually ‘recommendations’. The term ‘web standards’ actually came from the Web Standards Project. Surprising, I know.

The Idea Stage

Every new standard — ahem, recommendation — starts as an idea. That idea can come from the W3C, a browser vendor or other company, or folks like you and me. The W3C’s activities are organised into Working Groups, all of which function in their own unique way. Depending on where the idea fits in, it could surface on a mailing list, IRC, in a face-to-face, or possibly even on GitHub. From there, the Group discusses the idea and may opt to formalise it into a specification (also known as a ‘spec’).

Working Draft

The Working Draft (WD) is an initial stab at turning the idea into a spec. It maps out the feature’s implications, dependencies and interfaces. Things are typically pretty rough when the WD debuts. As more Group members (and the general public) begin to comment, the WD is revised.

Some browser makers may test an experimental implementation of the WD, but they do so knowing it’s likely to change. That’s why we shouldn’t use WD features. Once a WD has satisfied the Group’s technical requirements (‘Last Call’), it moves on.

Candidate Recommendation

When a spec becomes a Candidate Recommendation (CR), there is a call for implementations. Interested browser makers implement the spec and provide feedback on how clear and complete it is. The public is actively encouraged to comment, with a set deadline for doing so.

Even though we are pretty far along in the process here, the Group could iterate on the CR. Generally speaking, CRs are pretty solid — any changes should be nip/tuck work. However, it is possible to have a CR demoted back to WD or abandoned (as a ‘Note’). While it’s unlikely a CR will change, exercise caution when using one.

Proposed Recommendation

Two independent, interoperable implementations are required for a CR to progress to the next step. The CR also must have addressed any issues raised in the public review.

Once a spec becomes a Proposed Recommendation (PR), a deadline is set for an Advisory Committee review. If issues are found, the PR could be demoted to a CR or even a WD again, but if everything checks out, the W3C will officially give it its blessing.

At this point, the specification is finalised and becomes something we can use in our day-to-day jobs. And there you have it: the W3C’s process for creating a standard — er, ‘recommendation’.

Aaron Gustafson is a standards advocate at Microsoft and former manager of the Web Standards Project. He’s also written several books, including Adaptive Web Design

This article originally appeared in issue 269 of net magazine.