A quick video about web standards.

Transcript

This book is “Designing with Web Standards” from Jeffrey Zeldman. It helped to introduce a whole generation of developers to developing websites in ways that are not specific to certain browsers.

Yes. Before then, many developers built websites specifically for one browser cough Internet Explorer cough or had a different website for each browser. And by each browser, they meant website the top two browsers.

I’m Eric Eggert, a Web Accessibility Expert.

While these techniques are not used anymore, there are many people who still don’t use web standards as they are intended. We celebrate Blue Beanie Day, named after Zeldman’s headwear on the cover of the book, on November 30th, every year, as a reminder to use standards.

And while the book and the blue beanie became symbols for a better way to write websites, Jeffrey stood on the shoulders of giants, like the members of the Web Standards Project, people that worked mainly with browser vendors to have interoperable implementation of the standards.

Before this goes into a history lesson, let’s look at Web Standards today. The main Web Standards everyone thinks about are HTML (developed jointly in WHAT WG and W3C), CSS (developed in W3C) and JavaScript (by ECMA International). But there are many, many more standards. The W3C lists over 300 of them on their website.

But how does a Standard get there? I’ll look at the W3C process and wording here because that’s what I know best.

W3C is a consortium, meaning that companies pay a membership fee to get a seat on the table to talk about what should be a new standard. Then a working group is founded to work on a particular specification. You might have heard of the HTML Working Group, the CSS Working Group or the Accessibility Guidelines Working Group, but in fact there are over 35 of them.

Those groups work on a consensus basis, so everyone in the group has to be happy with the way going forward for progress to be made. Of course there are procedures to avoid veto situations.

Once work on a specification has started, a person or a small group inside the Working Group is chosen to be the editors of the specification, and they’ll create an Editor’s Draft of the document. Once the group agrees that the document is good enough, the Editor’s Draft is published on the Technical Reports page at w3.org/TR. It’s colloquially called the “TR space.”

Now not every Technical Report is intended to become a Standard, some are mere “Notes” which document information that are not technical or that didn’t get the complete backing for a full Standard after all.

Once a document that is supposed to become a standard is published in the TR space, it is called a First Public Working Draft (FPWD), and when it is subsequently changed — simply — Working Draft (WD).

Working Drafts are Work-In-Progress documents, they allow implementors to start with prototypical implementations and getting feedback of the community. Many early working drafts have sections of notes which detail questions of the group. After a couple of revisions, the specification advances to Candidate Recommendation (CR), when the Group decides that it is ready and the W3C Director — Tim Berners-Lee or a delegate — approves.

Candidate Recommendations satisfy the technical requirements of the group. This state invites a final wider review from the community and invites implementors to implement these standard. These documents are considered complete, aside from implementor’s feedback.

If it does not work out in any of these steps, the group can republish the CR or WD and sometimes that is requested to the Group by W3C’s Members (via the Advisory Committee, where every Member has one vote).

One feedback is collected, implemented and it is apparent that the specification is of sufficient quality to become a Standard, it can advance to Proposed Recommendation.

At this state W3C asks the Advisory Committee to review and approve the specification. Optimally everyone has done their due diligence before that point and it is approved. But in some instances members might have questions and or objections to a specification, especially if the members are not active in the particular area where the specification is put together.

If it succeeds, a new Recommendation is born. (Fireworks!)

Wait, you might think, why does it say “Recommendation” the whole time and not Standard? Is a Recommendation a Standard?

Basically, yes.

W3C recommends the wide deployment of its Recommendations as standards for the Web.

So, a Web Standard becomes a Standard through adoption, not just through publication of a document. This is a difference to other Standards, like ISO Standards from the International Standards Organization or EN Standards in the European Union, which often have a certain legislative support.

Web Standards are the foundation of the web. And having a Recommendation from W3C strongly suggests using it over proprietary solutions.

Now, Designing With Web Standards is surely not the most up-to-date book on web design — the latest edition was published in 2009. But its principles have laid the groundwork for so many things, including Mobile First and Responsive Web Design. That alone is worth reading many chapters of the book.

Tell me if you want more details in the comments below, hit like and subscribe if you’re interested in more content like this. If you want to give me feedback, use the Hashtag #askyatil on Twitter, or follow me on Twitter as @yatil – that’s always Y-A-T-I-L. You can support this channel at patreon.com/yatil.

Thanks for watching and happy Blue Beanie Day!