From W3C Wiki
Jump to: navigation, search

Restyle W3C: Towards a More Usable Spec Template

W3C is collaborating with the Jefferson University Interaction Design program to redesign the W3C specification template! The students are asking for your guidance, criticism and participation; and will be posting updates, sharing explorations and revisions, and requesting feedback via the Jefferson + W3C Collaboration blog. You can also post comments to the Specification Production Mailing List (please include [Restyle] in the subject line), which will be forwarded along. Currently open is a very basic survey.


This effort is about redesigning the W3C spec templates--reworking our content formatting, and tying it all together with a new visual style. The goal is to re-envisioning what the spec template can be, to make it more usable and to bring actual content above the fold. Everything about the spec template is in scope: HTML, CSS, boilerplate content.

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.


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, marking up, and designing that information.

See SpecProd/Restyle/Content.


This part is about the overal design of the spec: the look and feel of the specs and the layout and styling of the header, of metadata, etc. It's dependent on the boilerplate content being stabilized.

Some useful comments:

Personality of the design: authoritative, approachable, timeless (10-year design lifespan), modern (computer technology field, not historical literature)


This part is about the typography of the specs: the styling of headings, lists, paragraphs, tables, examples, notes, code snippets, IDLs, etc. It integrates with the overall Design aspect.

See existing documentation of markup conventions:

General Requirements

  • Both perusable (deeply-focused reading, by targetted section or from top to bottom) and scannable (skim to find relevant bits of info)
  • Accessible
  • Cross-platform, cross-device, & responsive
  • Beautifully and usably printable
  • Graceful degradation down to zero JS and/or zero CSS
  • Top quality, correct/readable/maintainable HTML and CSS, following best practices


The general audience for any W3C specification is the World Wide Web community at large. This community can be broken down further into various roles:

  • Specification Developers - spec editors, working group members, reviewers, and other community members who help develop the specifications
  • Implementers - software engineers who implement the specifications into browsers, for authors to use
  • Testers - QA engineers and volunteers, who write tests for implementations’ specification compliance
  • Authors - designers, developers, and educators who use the specified technology to build products, and who use the specification to teach themselves and each other
  • Overseers - lawyers, W3C management, AC reps, and others who don't care about the details of the specification but are there to manage the process

The design of the W3C specifications should encourage understanding of and involvement with the specifications. It should facilitate

  • the understanding of every reader--whether a twenty-year veteran of the Web standards process or an author or implementer encountering a W3C specification for the first time--of the purpose, status, and genesis of the specification and its openness to change
  • the engagement of implementers to give feedback and contribute tests as well as implement and correct their implementations
  • the engagement of testers in improving the test coverage of the specs and reporting errors and interop failures to the spec editors and implementers
  • the engagement of authors who are self-taught to play with and learn new technologies, to report problems, create documentation, and potentially get involved in implementation, test suite, or specification development
  • and the engagement of specification developers in each others’ work, to facilitate the coordination and interaction of the various parts of the Web platform.

Specifications are live documents, and this should be reflected in the template. W3C is an open standards organization, and this, too, should be reflected in the template.