This manual is a guide containing best current practice, written for editors and authors of W3C technical reports. No requirements for W3C publications are in this document. All requirements for W3C publications are in W3C Publication Rules.

Introduction

Written for editors and authors of W3C technical reports, this document assumes that the reader has mastered publishing on the W3C Web site, and is familiar with the Style Guide for Online Hypertext [STYLE-GUIDE]. It is a companion to the REQUIRED Technical Report Publication Policy [PUBRULES], called "pubrules" for short. Following the advice in this manual has benefits:

Chapter 2 covers validation. Chapters 3 and 4 cover accessibility and internationalization. Chapter 5 describes parts of a W3C technical report. Chapters 6, 7, and 8 cover errata, references and revisions. Chapter 9 introduces editing tools. Chapter 10 addresses Normative and Informative requirements, in particular RFC 2119 key words. Chapter 11 presents editorial guidelines, and, finally, chapter 12 documents commonly misspelled terms.

Bear in mind that our reports are used as world-class primary reference material. Readability across a wide variety of browsers and platforms is far more important than using jazzy features. At some point, what we write becomes history and is preserved on the Web through the W3C Persistence Policy [PERSISTENCE].

Validation

Note. It is the editor's responsibility to ensure that documents are valid before requesting publication.

Accessibility

Internationalization

Follow the guidelines in Internationalization Best Practices for Spec Developers [[INTERNATIONAL-SPECS]] when producing your specification. You might also find it helpful to complete a self-review early in the development process. If your specification touches on more complex issues, you can also reach out to the Internationalization Working Group for guidance.

Internationalization terminology, particularly terms related to Unicode, can be rather precise. To help avoid problems with the need to define these, import the [[Infra]] standard and [[I18N-GLOSSARY]]. Use the terms found in these documents instead of creating your own and link your use of these terms to the definitions found in these documents. Instructions on how to do this can be found in an appendix of the [[I18N-GLOSSARY]].

Write for a global audience

Keep in mind that W3C documents serve a global audience.

Unicode

Use U+XXXX syntax to represent [=Unicode code points=] in the specification. These are space separated when appearing in a sequence. No additional decoration is needed. Note that a [=code point=] may contain four, five, or six hexadecimal digits. When fewer than four digits are needed, the code point number is zero filled.

Use the Unicode character name to describe specific code points. Use of the character naming template is recommended.

Unicode assigns unique, immutable names to each assigned [=Unicode code point=]. Using these names in your specification when referring to specific characters (along with the code point in U+XXXX notation) will help make your specification unambiguous.

There are cases where doing this is overly pedantic and detracts from usability, but be cautious about being so informal as to impair meaning.

Character naming template

Internationalization specifications use (and we recommend the use of) this template for character references:

<span class="codepoint" translate="no"><bdi lang="??">&#xXXXX;</bdi> 
[<span class="uname">U+XXXX Unicode_character_name</span>]</span>

Some notes about the markup used. The bdi element is used to ensure that example characters that are [=right-to-left=] do not interfere with the layout of the page. The lang attribute should be filled in with the most appropriate [[BCP47]] [=language tag=] to get the correct font selection (and other processing) for a given context. Examples in East Asian languages (such as Chinese, Japanese, or Korean) or in the Arabic script can sometimes require greater care in choosing a language tag.

Translations

W3C has no official translations of its technical reports. W3C does encourage people to translate the technical reports and helps to track translators and translations.

Make your specification more readable by adding markup to distinguish common words from keywords in your language. Mark up every occurrence. Use translate="no" as an attribute to communicate to translators that the keyword is part of the [=vocabulary=] of a formal language rather than part of the [=natural language=] text of the document. For example:

<p>The title attribute of these elements may be used 
to provide the full or expanded form of the expression.

becomes:

<p>The <code translate="no">title</code> attribute of these elements may be used 
to provide the full or expanded form of the expression.

A French translator would then know not to translate title to titre.

Do not invent elements to replace natural language. For example, do not use <must/> and a stylesheet to render MUST. Other languages may need grammatical agreement with the sentence's subject, e.g., in French, MUST will become DOIT if the subject is singular, or DOIVENT if it is plural. Use standard markup instead.

The Parts of a Technical Report

As of November 2005, pubrules [PUBRULES] includes a technical report template.

Document Title

The title of your document in the document head and on the technical reports index [TR] will read as follows. Optional elements are in square brackets.

Title [(ACRONYM)] ["Specification"] ["Part" Part_Number] [: Subtitle] ["Module"] [(nth "Edition")] ["Version" Version_Number]

See pubrules [PUBRULES] for information about the use of "version" and "edition". "Level" and "revised" are deprecated. Try not to invent a new titling convention.

Capitalize title words following U.S. usage.

Editors and Authors

Managing Changing Affiliations

Editor/Author affiliations change over time. Here are examples that illustrate the suggested approach for managing them.

Still editor
Richard Ishida, W3C (and before at Xerox)
François Yergeau, Invited Expert (and before at Alis Technologies)
Jane Doe, MyCompany (and before at ThierCompany, and at HisCompany, and at HerCompany)
No longer editor
Martin J. Dürst (until Dec 2004 while at W3C)
Misha Wolf (until Dec 2002 while at Reuters Ltd.)
Tex Texin (until Dec 2004 while an Invited Expert, and before at Progress Software)
FitzChivalry Farseer (until Oct 2005 while at AnyCompany, and before at ThisCompany, and at ThatCompany)

Abstract

Give each document an Abstract (a few paragraphs at most) that summarizes what the document is about. The Communications Team may use the Abstract as a whole or in part to publicize your work. Write it for a non-technical audience.

Status Section

The "Status of This Document" section describes the document status and publication context on the publication date. Pubrules [PUBRULES] states the requirements for the status section of each type of technical report (e.g., use of customized and boilerplate text).

Since the status section does not change over time, express it in terms that will be valid over time (e.g., avoid the word "new"). Indicate the anticipated stability of the document while recognizing that the future is unknown. Readers are responsible for discovering the latest status information (e.g., by following the latest version link, or visiting the W3C technical reports index [TR].

The custom paragraph is very important as it actually contains information! In it, you should explain where a part of the energy of the group has been invested. The custom paragraph should help a reader decide "I really should read this draft." This implies that you shouldn't paste it in from somewhere else. It should be very specific to this document.

TimBL expressed the goal of the custom paragraph this way, "Don't be afraid of being honest about the relevant techno-political situation." In the custom paragraph, make th case for why someone should read this draft.

In the custom paragraph, include what you would reply to a Member or colleague who asked you such things as:

Errata

All Recommendations have errors in them. They link to an errata page that evolves over time. Since the errata page changes over time but a specific version of a Recommendation does not, place the errata page outside of the /TR hierarchy. There is an expectation that documents in the "TR zone" will not evolve over time [PERSISTENCE]. For example, locate errata pages in the portion of the Web space dedicated to the relevant Working Group or Activity.

Clearly indicate on the errata page:

For example (shown here without links):

This document:
http://www.w3.org/Style/css2-updates/REC-CSS2-19980512-errata
Last revised:
$Date: 2016/07/10 16:55:10 $
This document records known errors in the document:
http://www.w3.org/TR/1998/REC-CSS2-19980512
The latest version of the CSS 2 Recommendation:
http://www.w3.org/TR/REC-CSS2

On the errata page, list the newest entries nearer to the top.

Entries on an errata page

For each entry on the errata page, provide:

  1. A unique identifier
  2. The date it was added to the errata page
  3. A classification of the error (e.g., editorial, clarification, bug, known problem with the document itself)
  4. A short description of the problem and what part of the Recommendation is affected.
  5. Any proposed corrections and whether those corrections would affect conformance of documents or software
  6. Any normative corrections; see the section on Errata Management in the W3C Process Document ([PROCESS] section 6.7.1) for more information about normative corrections

Do no remove entries from the errata page; if a correction turns out to be incorrect, just add another entry (with a cross reference).

References

Bibliography Extractor

The SpecRef tool, an Open-Source, Community-Maintained Database of Web Standards & Related References, contains an exhaustive of references.

The W3C Bibliography Extractor [BIB-EXTRACT] will automatically generate a list of references in W3C style.

Citation

Reference links (e.g., "[XML]") link at least the first mention of a source to the References section and take the form:

<cite><a href="http://www.example.org/example">Full Name</a></cite> [<cite><a href="#ref-REFNAME">REFNAME</a></cite>]

Parentheses around square brackets can be omitted unless the parentheses would contain a section number.

References links occur at minimum at the first mention of the source. Spell out what the reference link refers to at least in the first occurrence, e.g.:

This is discussed in Namespaces in XML [XMLName].

or

This is discussed in the XML namespaces specification [XMLName].

and not

This is discussed in [XMLName].

Citing a Reference From Within a Document

When linking from the middle of the document to an external resource:

  1. Ensure that the link text, title, and context indicate you are leaving the document, and
  2. After the link, link to the reference in the references section, and indicate section, page, or whatever is useful for those when the link is unavailable (e.g., when printed).

Thus, for example:

...as is done for the 'outline' property of CSS2 ([CSS2], section 18.3).

References Section

Normative and Informative References

See Normative References and considerations by the Director.

Revisions

See the W3C Process Document ([PROCESS] section 6.7) for instructions on modifying a W3C Recommendation.

Note. When a document is revised, the original publication date remains the same (and on the technical reports index [TR] as well); see pubrules [PUBRULES] for more detail.

Be careful not to break links in revisions. If your document uses latest version URIs with a fragment identifier, unless those anchors are maintained across versions, links will break.

Editing tools

Though the HTML or XHTML version of your specification is always the definitive one, many editors find the use of a tool easier to work with.

The most popular editing tools are Bikeshed and respec.

For help with this process, you can ask the experts on the public mailing list spec-prod@w3.org [SPEC-PROD].

Normative material

Normative & Informative sections

It is important that informative (non-normative) material is clearly distinguished from normative material. To this end:

RFC 2119 Key Words

Recent changes to ReSpec mean this is not the case in this document (which is based upon ReSpec), nor in other ReSpec generated documents.

Adhere to and credit RFC 2119 Key words for use in RFCs to Indicate Requirement Levels [KEYWORDS] (e.g., "MUST", "MUST NOT", "REQUIRED").

When these key words are used in the RFC sense, make them UPPERCASE, enclose them in the em element, and style them with CSS class of rfc2119 to make the UPPERCASE readable.

<em title="MUST in RFC 2119 context"
       class="rfc2119">MUST</em>

.rfc2119 {
  text-transform: lowercase;
  font-variant: small-caps;
  font-style: normal;
}

The author may explain why if these key words are not used in the RFC sense.

Where they are not required for interoperation or to limit behavior which has potential for causing harm these key words must not be used to try to impose a particular method on implementors where the method is not required for interoperability.

Editorial Guidelines

This section refers to editorial practice at W3C. It touches on grammar, spelling, punctuation, case, linking, appearance and markup.

Grammar

Spelling

Punctuation

Case, Combining Words, and Hyphenation

Miscellaneous

Linking

Using Examples

Images

Markup

Large Documents

Large single files that may be easy to print and search may not be easy to download. For large documents:

Inclusive terminology

Following the W3C Code of Conduct, W3C specifications are expected to be inclusive and facilitate diversity. As such, editors and authors are strongly encouraged to use a neutral and inclusive language to ensure the best environment possible for the whole W3C community.

Here are proposed alternatives for some terms that PubRules (see list of terms in JSON) shows a warning about:

Terms to avoid Possible alternatives

Internet Media Types

Commonly Misspelled Terms

W3C has reviewed its technical reports one by one since November 1999, for typographical errors. The following words appear often in those reviews and are easy to misspell.

anti-alias
hyphenate
ASCII
all caps
base64
lowercase, one word
Bézier
always capitalize, and accent the first e
braille
capitalize only when talking about Louis Braille
built-in
hyphenate when used as an adjective or noun, not when built is a verb
color space
two words
DTDs
no apostrophe (see [PLURAL])
dingbat
one word
ECMAScript
one word, cap S
et al.
no full stop after "et"
full stop (.)
Full stop is the formal name. Dot and period are good aliases.
hash (#)
also number sign, usually not pound sign, crosshatch or octothorpe
heading
Term for h1-h6. Tables and HTTP have headers.
HTTP/1.0
needs slash when referred to as a protocol, none in free text
HTTP/1.1
needs slash when referred to as a protocol, none in free text
home page
two words
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
MIME type
now Internet media type (MIME type is two words. MIME is all caps.)
namespace
lowercase unless referring to the Namespaces in XML specification by name
number sign (#)
also hash, usually not pound sign, crosshatch or octothorpe
on-line
hyphenate
PDF
all caps
PostScript
cap S
read-only
hyphenate
Real-Time Communication, real-time communication, real-time communications, RTC
In titles and headings, capitalize all words = Real-Time Communication
For the generic idea in sentences, lowercase = real-time communication or real-time communications — including with the acronym = real-time communications (RTC)
ruby
lowercase
schema
lowercase
schemas
preferred to schemata
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
URIs
no apostrophe (see [PLURAL])
user agent
lowercase
user interface
lowercase
Web (on its own)
always capitalize
Web (as part of a phrase)
Either capitalize or lower case "Web" (e.g., Web developer or web developer, Web project or web project, Web page or web page, Web application or web application
Webmaster, webmaster
one word, either capitalize or lower case
Web page, web page
two words, either capitalize or lower case "Web"
Web site, web site, website
two words (capitalize or lower case "Web") or one (lower case)
well-formed
hyphenate
white space
two words
worldwide
one word
World Wide Web
three words, no hyphen
W3C Note
not W3C NOTE

Acknowledgments

Thank you to Karl Dubost (W3C). Thank you to Philip Gallo for the pencil image and to Paul Harmon and to E.K. for artwork used in earlier versions. The following people contributed to this compilation:

References

[AH]
American Heritage® Dictionary, 4th Edition. Houghton Mifflin Company, 2000. This book is on-line at http://www.bartleby.com/61.
[BIB-EXTRACT]
W3C Bibliography Extractor, Dominique Hazaël-Massieux, 2003. This tool is on-line at https://www.w3.org/2002/01/tr-automation/tr-biblio-ui.
[CHARNAMES]
Unicode character names, M. Davis, M. Dürst, et al., 25-27 August 2001. This email thread is on-line at https://lists.w3.org/Archives/Public/www-international/2001JulSep/thread.html#133.
[CHARTS]
About the Online Code Charts, The Unicode Standard, Version 1.1 or later. The Unicode Consortium, 2001. Unicode code charts are on-line at http://www.unicode.org/charts/About.html.
W3C Link Checker, W3C QA Activity, 1999-2011. This service is on-line at https://validator.w3.org/checklink.
[CLICK-HERE]
Don't use "click here" as link text, Aaron Swartz. W3C QA Team, 2001. This QA tip is on-line at https://www.w3.org/QA/Tips/noClickHere.
[CSSVALIDATE]
W3C CSS Validation Service, W3C QA Activity, 1997-2004. This service is on-line at https://jigsaw.w3.org/css-validator.
[DOMAINS]
Reserved Top Level DNS Names, D. Eastlake, and A. Panitz. The Internet Society, June 1999. This RFC is available at https://www.ietf.org/rfc/rfc2606.txt.
[EDITORS]
W3C Editors Home Page, Dominique Hazaël-Massieux for the W3C Communications Team, 2003. This list of resources for editors is on-line at https://www.w3.org/2003/Editors/.
[GRM]
Frequently Asked Questions, The Gregg Reference Manual Instructor Site, Glencoe/McGraw-Hill, 2000. This FAQ is on-line at http://www.glencoe.com/ps/grm/faqs.
[IPRFAQ]
Intellectual Property FAQ, W3C, 20 June 2000. The latest version of this document is http://www.w3.org/Consortium/Legal/IPR-FAQ.
[KEYWORDS]
Key words for use in RFCs to Indicate Requirement Levels, S. Bradner. The Internet Society, March 1997. This RFC is available at https://www.ietf.org/rfc/rfc2119.txt.
[M-W]
Merriam-Webster OnLine: Collegiate Dictionary, 10th Edition. Merriam-Webster, Incorporated, 2000. This book is on-line at http://www.m-w.com.
[MANAGE]
Document Management for Web Specs, D. Connolly. W3C, 1995-1999. This guide is on-line at http://www.w3.org/MarkUp/SGML/spec-mgmt.
[PERSISTENCE]
Persistence Policy, T. Berners-Lee, 1999. This policy is on-line at https://www.w3.org/Consortium/Persistence.
[PLURAL]
Infrequently Asked Questions Concerning the Proper Spelling of 'DTD' in its Plural Form, R. Cover, updated 4 January 2001 or later. This document is on-line at http://xml.coverpages.org/properSpellingForPluralOfDTD.html.
[PROCESS]
World Wide Web Consortium Process Document, Charles McCathie Nevile, Editor. W3C, 1 March 2017. The latest version of this document is https://www.w3.org/Consortium/Process.
[PRONOUNS]
Personal pronouns in specifications, M. Dürst, 13 May 2000. This email message is https://lists.w3.org/Archives/Public/www-international/2000AprJun/0058.
[PUBRULES]
Technical Report Publication Policy, the W3C Team. W3C, 2000-2017. This document is on-line at https://www.w3.org/Guide/pubrules.
[REF-TITLES]
please use titles, not addresses, as link text, D. Connolly, 10 February 2000. This email message is on-line at https://lists.w3.org/Archives/Public/www-html-editor/2000JanMar/0103.
[REGISTER-1]
How to Register an Internet Media Type for a W3C Specification, J. Reagle, M. Dürst, P. Le Hégaret, 2002-2006. This Web page is on-line at https://www.w3.org/2002/06/registering-mediatype2014.
[REGISTER-2]
TAG Position on Use of Unregistered Media Types in W3C Recommendations, N. Mendelsohn, 4 August 2006. This email message is https://lists.w3.org/Archives/Public/www-tag/2006Aug/0012.
[SPEC-PROD]
spec-prod@w3.org. W3C, 1998-2001. Subscribe to this public mailing list at http://www.w3.org/Mail/Lists and view its archive at https://lists.w3.org/Archives/Public/spec-prod.
[STYLE-GUIDE]
Style Guide for Online Hypertext, T. Berners-Lee. 1992-1998. This guide is on-line at https://www.w3.org/Provider/Style.
[TR]
W3C Technical Reports and Publications, W3C, 1995-2017. This Web page is on-line at https://www.w3.org/TR.
[TRANSLATE]
Translations at W3C, W3C, 1997-2003. This Web page is on-line at https://www.w3.org/Consortium/Translation.
[VALIDATE]
W3C Markup Validation Service, 1994-2013. This service is on-line at https://validator.w3.org.

External Links

The prose links to the following references as illustrations. They are informative, listed here for print use.

[CSS2]
Cascading Style Sheets, level 2 section 18.3, B. Bos, H. W. Lie, T. CElik, and I. Hickson, Editors. W3C, 2011. This example is on-line at https://www.w3.org/TR/2011/REC-CSS2-20110607/ui.html#propdef-outline.
[EXCAL]
Excalibur, R. Zaccone, 2001. The Excalibur home page is http://www.eg.bucknell.edu/~excalibr/excalibur.html.
[HTML]
HTML 5.1. Steve Faulkner, et al., Editors, W3C, 2016. The latest version of the HTML is available at https://www.w3.org/TR/html/.
[ISPELL]
International Ispell, G. Kuenning et al. 1971-2001. The Ispell home page is http://fmg-www.cs.ucla.edu/fmg-members/geoff/ispell.html.
[SCHEMA-DATATYPES]
XML Schema Part 2: Datatypes sections 3.2.9 through 3.2.14.1, P. V. Biron, and A. Malhotra, Editors. W3C, 2001. The latest version of XML Schema: Datatypes is available at https://www.w3.org/TR/xmlschema-2.
[XML]
Extensible Markup Language (XML) 1.0 (Fourth Edition) section 2.5, , T. Bray, J. Paoli, E. Maler, C. M. Sperberg-McQueen, F. Yergeau, Editors. W3C, 2006. This example is on-line at https://www.w3.org/TR/2006/REC-xml-20060816/#sec-comments.
[XML1]
Extensible Markup Language (XML) 1.0 (Fourth Edition), T. Bray, J. Paoli, E. Maler, C. M. Sperberg-McQueen, F. Yergeau, Editors. World Wide Web Consortium, 16 August 2006, edited in place 29 September 2006. This edition of the XML 1.0 Recommendation is http://www.w3.org/TR/2006/REC-xml-20060816/. The latest edition of XML 1.0 is available at http://www.w3.org/TR/xml/.