How design could save the W3C

While preparing my HTML workshop, I’ve been re-reading W3C specs in far further detail than I ever would’ve imagined. The reading experience is far from delightful. Not only is the text the entire browser width in measure, but it’s dense and laborious to read. No wonder browser vendors have traditionally missed subtle details.

Directly working on the improving the writing and review process would be far too difficult, I needed something and I needed it now. I set off to make the reading experience better.

My goal was to add some sane styles to the pre-existing spec pages that would vastly improve the reading experience.

I whipped up a quick bookmarklet to load some custom CSS. I was already happy. I wrote to Anthony; a typical kind of email that we would trade:

An email traded between Anthony and I

I promptly pushed my progress to github and added Anthony as a contributor.

Having attempted to read through some of the specs myself, I had to agree. They are by nature very dense documents, made all the worse by a lack of proper typographic consideration. Neither of us was up to the task of rewriting the specs themselves, but improving the readability of the page was a good starting point.

The typefaces

I wanted the titles to be large and image-like. No spidery, thin text; it needed to cement the content that followed. I chose Chunk from The league of Movable Type and used @font-face.

The main body typeface specified by the w3c is font-family: sans-serif, which resolves to Arial on Windows and Helvetica on Mac OS. Not a terrible choice, but while these typefaces give a clean, structured feel to the page, they are less ideal for large blocks of text. We switched out sans-serif in favour of Matthew Carter's Georgia, whose larger x-height and excellent hinting makes it much better suited to extended reading on screen.

The measure

When a typographer refers to “the measure”, they mean the width of the text body. Simply put, when copy is too wide or poorly spaced it becomes difficult to read. This was the first issue that I had; physically scanning back and forth over the text was annoying and frustrating.

The general rule for a comfortable measure is around 60–70 characters per line. Taking into account that each character averages out to around 0.5em in width, setting a measure of 33em should keep each line within the optimum range.

Old measure New measure

Useless information

Why do I want to know about this version, the previous version, editors and previous editors before I’d read any of the spec or its introduction? Perhaps this is useful internally, but for the rest of us, its just visual noise that could be removed.

Poorly defined hierarchy

A spec is hard to scan, its even harder to decipher the different levels of hierarchy. We decided to make a visual feature and pull the numbering out to the left, creating a column that overhung the original left margin.

We added an additional colour palette based off #066 to help clarify the multiple levels of headings. Colour variation is much easier for the eye to differentiate than the hierarchical number system the w3c currently employs. Additionally, #066 blends easily with the black body text — letting us emphasise links without them interrupting the reading flow. It also gives a nice tonal range to work with, all the way down to #cff which works well as a background tint behind black (which we used for the main code blocks).

#000 #033 #066 #399 #6cc #cff

Putting it together

Next up, a userscript version was in order.

The script is really simple; it just adds the styles and script tags into spec pages. The external script and style files are currently hosted straight out of the Github repository.

Going forward

We have spent a bit of time writing override rules to clean up the w3c's table and list styles and to reduce some of the more unwieldy page sections. Due to the complexity and variety of spec pages, it's an ongoing project. The styles will continue to be updated as we come across more awkward type treatments throughout the specs.

We haven’t styled every single element that we’ve come across through the W3C specs, so if you find something that looks out of place and feel like getting your hands dirty, please fork the project and send me a patch.

What would we like to see happen with this alternate stylesheet? w3c adoption. Until the w3c put further respect in to the standards that they govern for the world, we will continue to live in a web environment that has a poor understanding for its medium. Now, with WHATWG, communication and transparency and a “do-over” in HTML5, we can change the face of the future of the web. Now thats a project worth working on.

Before/After

– Best, Anthony + Ben