Contents

Restyle W3C: Towards a More Usable Spec Template

Scope

This effort is about redesigning the boilerplate content, reworking our content formatting, and tying it all together with a new visual style.

This effort is not about adding new functionality to our specification format, such as incorporating test results, issue tracking, or other systems. It is only about reworking how we present the spec content in static (hypertext and printed) form.

Boilerplate

This branch of the Restyle effort is about redesigning the content of the W3C spec template.

The first step is identifying what information needs to be in the template.

The second step will be organizing, ordering, and designing that information.

Implement in Bikeshed and Respec for Editor's Drafts to get beta-use feedback. Respond to all feedback.

Continue refinement until everyone is happy.

Hand over to W3C for deployment.

(Some of these can be done in parallel, e.g. typgraphic design depends on visual design choices like font and color palette, but not on wireframes/markup/coding of the header being complete. Implementation in bikeshed could be earlier, and randomly output one of 3 designs until there's clear consensus on one. Etc.)

Audiences

Two key audiences:

Implementers

Authors

No consensus on which is more important. Two viewpoints so far:

Authors are more important, and specs should be optimized for them even at the expense of implementers.

Authors and implementers are equally important, and specs should be optimized for both, not optimized for one at the expense of the other.

An Audience Priority Proposal

With the advent of browse by searching and Google, the era of "specs are primarily for browser implementers" is over.

All sorts of people will find themselves at W3C specifications just by searching for the respective technologies, and we should therefore take that strongly into account.

Prioritize larger audiences over smaller, and take into account subset relationships

There are far more web authors (those that write some HTML, maybe some CSS) than web developers (those that write HTML+CSS+JS+etc.)

web developers tend to also be web authors, thus anything that benefits web authors will also benefit web developers

There are far more web developers than browser implementers.

browser implementers tend to also be web developers, thus anything that benefits web developers will also benefit browser implementers

Prioritize builders over talkers

It's more important that a browser implementer understand and properly implement a specification, as that's what actually impacts interoperability, than it is that a standards representative / AC rep do so in order to debate a standard.