Position Paper: Workshop on Quality Assurance at W3C
3-4 April 2001

Proposal for a W3C Publications Style Guide

Susan Lesch
W3C Communications Team
3689 Martha St.
San Diego, CA
92117-1814 USA
Voice: +1.858.483.4819
Fax: +1.509.272.7791
Email: lesch@w3.org

Table of Contents


This paper proposes that W3C produce a set of editorial recommendations for authors and editors to refer to when writing technical reports, called TRs for short. Their number and complexity is increasing. At the time of this writing there were 280 listed on the W3C TR index page. Guidelines may help us to publish consistently high quality specifications. They would supplement and not replace our mandatory publication rules, which are specific to publication day.

Contents of a Style Guide

The guide could include any properties shared by technical reports that are not addressed in publication rules. We could bring How to Write a W3C Technical Report and other help files together in one place. We could add:

Goals for This Workshop

Possible goals for this Workshop:

  1. Ask whether people want to extend publication rules to include a style guide.
  2. Learn what NIST's publication guide does for NIST.
  3. Identify other style guides.


Three years ago, Tim Boland of NIST posted a request for comments to the W3C www-style@w3.org mailing list. Tim's work covered not only CSS1 but CSS2 as well. Four days later, Eric Meyer announced a preview of what became the W3C CSS1 Test Suite. The suite was a joint effort of W3C, NIST, and Case Western University.

The second inkling I had about QA and the Web came when Daniel Dardailler who wrote an article for the November 1999 Member Newsletter proposing W3C QA. Daniel had suggested that we might examine technical reports for complexity and size.

On October 16, 2000, Karl Dubost attended a Communications Team teleconference. Karl showed how well the QA and Communications Teams work together.

Current Reviewers

To date, W3C technical report reviews may be initiated by eight or more parties. Please excuse any oversights in this list; there may be more than eight. The Webmaster does the first review for conformance to our publication rules. In addition, we have four areas inside W3C that may be reviewing technical reports:

and three areas outside the Team:

Future Reviewers

There are a number of ways to look at technical report reviews for the future.


We have looked at the goal of improving the quality of W3C publications through a style guide. We also reviewed a brief history of one editor's work at W3C, the current situation, and a sketch for the future. I look forward to input from Workshop attendees during the discussion period, and from other readers of this paper. Thank you.

Appendix A - Notable Style Guides

The following documents address editorial production by standards bodies. With two exceptions, they are publicly accessible. This was not created as a definitive list. Additions and corrections are welcome.

Appendix B - What Is Checked Now

The Webmaster checks for conformance to W3C Publication Rules.

Compiled in December 2000, the following list is what SL tries to check after publication at Last Call Working Draft, Candidate Recommendation, and Proposed Recommendation.




Case, Combining Words, and Hyphenation





Appendix C - Commonly Confused Terms

The following table lists the forty or so most commonly confused terms used in W3C technical reports since November, 1999. In some cases there are good arguments for usage other than that listed here, and these differences are yet to be resolved.

Term Explanation
anti-alias hyphenate
ASCII all caps
base64 lowercase, one word
Bézier always capitalize, and accent the first é
braille capitalize when talking about Louis Braille
built-in hyphenate when used as an adjective or noun, not when a verb
dingbat one word
ECMAScript one word, cap S
et al. no full stop after "et"
full stop (.) not period; dot or decimal point are good alternates
heading term for H1-H6 (tables and HTTP have headers)
HTTP/1.0 needs slash
HTTP/1.1 needs slash
Java cap J
JavaScript cap S
Level 1, 2, 3 cap L when referring to a W3C technical report
line feed two words
lowercase one word
markup one word, except when a verb
MIME type two words, MIME is all caps
namespace lowercase unless referring to Namespaces in XML
number sign (#) not crosshatch
on-line hyphenate
PDF all caps
PostScript cap S
read-only hyphenate
ruby lowercase
schema lowercase
semicolon one word
stand-alone hyphenate
style sheet two words
subset no hyphen
superset no hyphen
uppercase one word
URI reference usually not URI Reference or URI-Reference
user agent lowercase
user interface lowercase
Web always capitalize
Web site two words, capitalize Web
well-formed hyphenate
white space two words
worldwide one word
World Wide Web three words, no hyphen
W3C Note not W3C NOTE