W3C Manual of Style

Also On This Page →

Status •
Contents

Publication Policies

Resources

Tools

Status of This Document

This is the W3C Manual of Style based on How to Write a W3C Technical Report (W3C Member-only link). This manual is a guide containing best current practice. No requirements for W3C publications are in this document. All requirements for W3C publications are in W3C Publication Rules [PUBRULES].

Helpful resources for editors and authors are kept on the W3C Editors Home Page [EDITORS]. Notes on document management are available [MANAGE]. When in doubt, ask for help on the public mailing list spec-prod@w3.org [SPEC-PROD].

Please send your comments to the public mailing list spec-prod@w3.org (archive). If for any reason you do not wish your contributions to be credited in Acknowledgments, please indicate this in your email.

Introduction
Validation
Accessibility
Internationalization
The Parts of a Technical Report
Errata
References
Revisions
XML, XMLspec, XSLT and Production
RFC 2119 Key Words
Editorial Guidelines
Internet Media Types
Commonly Misspelled Terms
Acknowledgments
References
Change History
To Do List

1. 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:

Non-native English readers, native English readers, and translators will find your text easy to read and implement.
All audiences can concentrate on ideas rather than the mechanics of reading.
Polished at early public maturity levels, clean copy eliminates multiple "typo" reports.

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 XMLspec and XSLT. Chapter 10 addresses 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].

2. Validation

Make sure there are no broken links in your documents at the time of publication. Some services on the Web may help you with this, including the W3C Link Checker [CHECKLINK]. Append ",checklink" to a W3C URI to invoke the link checker.
Make sure your technical report validates in the W3C Markup Validation Service [VALIDATE]. Append ",validate" to a W3C URI to invoke the validator.
Make sure your technical report validates in the W3C CSS Validation Service [CSSVALIDATE]. Append ",cssvalidate" to a W3C URI to invoke the CSS validator.
Make sure any examples in your document validate as well.

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

3. Accessibility

Follow the Web Content Accessibility Guidelines 1.0 (WCAG) [WCAG]. Can simpler words express your ideas? Is your text marked up with structural elements? Are alternatives provided for auditory and visual content?
Use two or more accessibility evaluation tools such as Bobby, The Wave, or A-Prompt [EVALUATE].

4. Internationalization

Follow the Character Model for the World Wide Web 1.0: Fundamentals W3C work in progress [CHARMOD]. Does your specification define protocols or format elements? If it does, define when conversion to legal URI reference characters takes place, and do so as late as possible.

4.1 Unicode

When specifying characters, refer to The Unicode Standard; see section 8 of the Character Model for the World Wide Web 1.0: Fundamentals [CHARMOD]. The Unicode Consortium gives guidelines for how to cite their standards; see [UNICODE]. Refer to individual characters in any of three ways; see the email thread "Unicode character names" [CHARNAMES]:

by codepoint (e.g., U+002E)
by formal Unicode name (e.g., full stop); see [CHARTS]
by Unicode alias (e.g., dot, or decimal point, or period); see [CHARTS]

4.2 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.

A central translation page includes links to pages that document translations of particular specifications [TRANSLATE].
Read the W3C Intellectual Property FAQ, Can I translate one of your specifications into another language? and Can I create the "official" translation? ([IPRFAQ] sections 5.6 and 5.7).

Although technical reports are written in U.S. English, examples and wording should not rely on conventions and idioms used only in the United States (e.g., "ZIP code"). Use international examples (e.g., "postal code") wherever possible.

Make your specification more readable by adding markup to distinguish common words from keywords in your language. Mark up every occurrence. For example:

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

becomes:

The <code>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.

First person pronouns ("I," "we") which are hard to translate should not be used in the text of examples. See the email message "Personal pronouns in specifications" [PRONOUNS]. Avoid "my" and "me" in examples (e.g., use "userResource" and not "myResource").

Specifications should not directly address the reader as well. Translating second person singular pronouns is a hard task if the language distinguishes between various forms like formal and informal of "you," hence avoid "you."

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.

4.3 Style for Dates

5/6/03 to denote a date is ambiguous in the international context (the example could mean 6 May or 5 June). Either spell out the month (6 May 2003) or use an ISO-8601-derived form (2003-05-06). XML Schema Part 2: Datatypes ([SCHEMA-DATATYPES], sections 3.2.9 through 3.2.14.1) formally explains how to write dates in XML documents.

5. The Parts of a Technical Report

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

5.1 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.

5.2 Editors and Authors

5.2.1 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)

5.3 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.

5.4 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:

Are we requesting that people implement this specification? If so, where should experience reports be sent?
Are we requesting people do not implement the specification until a later date? What sort of damage do we expect to inflict on those who do by future changes to the document?
Does it reflect the consensus of a W3C Working Group? (Pay attention to the authors and acknowledgments.)
Are there any changes expected?
Do we maintain a page of background information (e.g., the P3P FAQ [P3PFAQ])?
For pre-release drafts, state in the status section any limits on redistribution, such as "Member confidential."

6. 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:

The last modified date for the errata page.
The URI of the source document (i.e., the one with the errata).
Where to find the latest version of the source document.

For example (shown here without links):

This document:: http://www.w3.org/Style/css2-updates/REC-CSS2-19980512-errata
Last revised:: $Date: 2007/11/15 20:34:27 $
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:

A unique identifier
The date it was added to the errata page
A classification of the error (e.g., editorial, clarification, bug, known problem with the document itself)
A short description of the problem and what part of the Recommendation is affected.
Any proposed corrections and whether those corrections would affect conformance of documents or software
Any normative corrections; see the section on Errata Management in the W3C Process Document ([PROCESS] section 7.6.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).

7. References

7.1 Bibliography Extractor

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

7.2 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].

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

and not

This is discussed in [XMLName].

7.3 Citing a Reference From Within a Document

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

Ensure that the link text, title, and context indicate you are leaving the document, and
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 'page' property of CSS2 ([CSS2], section 13.3.2).

7.4 References Section

All entries in a references section should be referred to in the prose. If an entry is not referred to from the body of the document, make it clear why it is in the References section.
If a reference is a W3C Recommendation track technical report that has not reached Recommendation, state in the References section that it is "work in progress."
It is helpful to include references to both persistent resources and their latest version. Use titles for links. If there is an institutionalized identifier (URI) for a document, cite the most specific identifier. For example, usually you would link the title to http://www.w3.org/TR/1999/REC-html401-19991224 rather than to http://www.w3.org/TR/html4/. For more information on using versioned and unversioned identifiers, refer to the Character Model for the World Wide Web 1.0: Fundamentals ([CHARMOD] section 8).
An entry in a references section takes this form:
- Title, inside a (if available), inside cite
- Comma-delimited list of authors' names
- If there are no authors, use editors instead if available. Following the last family name, say "eds." or "Editors."
- Publisher, followed by the date of publication in the form DD Month YYYY
- A sentence containing a text-only URI.
- When available, a sentence ending in the latest version URI
Example:

[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/.

Markup for the example above:
```
<dl>
<dt><a id="ref-XML1" name="ref-XML1">[XML1]</a></dt>

<dd><cite><a href="http://www.w3.org/TR/2006/REC-xml-20060816/">Extensible
Markup Language (XML) 1.0 (Fourth Edition)</a></cite>,
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 <a 
href="http://www.w3.org/TR/xml/">latest edition of XML 1.0</a>
is available at http://www.w3.org/TR/xml/.</dd>
```
Reference titles are recommended, not the "URI-in-your-face" idiom, as link text; see [REF-TITLES]. For example, Do use: <cite><a href="http://www.w3.org/TR/1999/REC-html401-19991224/">HTML 4.01 Specification</a></cite>. Do not use: <cite><a href="http://www.w3.org/TR/1999/REC-html401-19991224/">http://www.w3.org/TR/1999/REC-html401-19991224</a></cite>.

7.5 Normative and Informative References

Normative references should be to stable and mature resources (e.g., only Recommendations).

8. Revisions

See the W3C Process Document ([PROCESS] section 7.6) for instructions on how to revise a technical report.

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.

9. XML, XMLspec, XSLT and Production

Though the HTML or XHTML version of your specification is always the definitive one, many editors find an XML original easier to work with, and sometimes an XML version is provided as an alternative format. The W3C XML Specification DTD (XMLspec) used to produce many of W3C's XML-related Recommendations can facilitate this work. XMLspec is fully documented [XMLSPEC]. Various XSLT style sheets are in use and continual development to output the final technical report [XSLT]. For help with this process, you can ask the experts on the public mailing list spec-prod@w3.org [SPEC-PROD].

10. RFC 2119 Key Words

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 to make the UPPERCASE readable.

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

.RFC2119 {
  text-transform: lowercase;
  font-style: italic;
}

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.

11. Editorial Guidelines

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

11.1 Grammar

Delete repeated words.
Check subject-verb agreement.
Break long sentences.
Eliminate contractions (e.g., "don't" should read "do not")?

11.2 Spelling

Spell-check using a U.S. English dictionary. Append ",spell" to a W3C URI to invoke W3C's spell checker.
Free dictionaries are also available on the Ispell home page [ISPELL] for UNIX and the Excalibur home page [EXCAL] for Mac OS.
W3C uses Merriam-Webster's Collegiate^® Dictionary, 10th Edition [M-W], on the Web as the spelling arbiter because it is free, on-line, and available to every technical report author and editor. If a word does not appear there, use the American Heritage^® Dictionary, 4th Edition [AH]. Other dictionaries are used as needed (for example, Random House and Webster's unabridged, Oxford and Oxford Concise).
W3C uses U.S. English (e.g., "standardise" should read "standardize" and "behaviour" should read "behavior").
Form the plural of abbreviations, initialisms and acronyms without an apostrophe (e.g., the plural of URI is URIs not URI's). See the FAQ "Infrequently Asked Questions Concerning the Proper Spelling of 'DTD' in its Plural Form" [PLURAL].

11.3 Punctuation

Use correct punctuation. A hard copy of The Chicago Manual of Style or The Gregg Reference Manual may be of some help.
Remember you are typing HTML or XML not TeX. Use quotation marks rather than grave accents and apostrophes to quote text (e.g., ``value'' should read "value").

11.4 Case, Combining Words, and Hyphenation

Capitalize W3C entities to match the W3C Process Document [PROCESS] (e.g., Working Group, Recommendation).
Make the case, number of words, and hyphenation in terms match chapter 12.

11.5 Miscellaneous

Spell out acronyms and initialisms in their first occurrence in prose, for example, "Internet Engineering Task Force (IETF)" or "Internationalization (I18N)." In subsequent occurrences when they are not spelled out, use abbr and acronym elements, and give them title attributes. For the purposes of HTML and XHTML 1.0, mark up as an acronym anything that can be pronounced as a word, and mark up initialisms and abbreviations as abbr.
Check references (most commonly, for no full stop after the et in et al.). Do the entries match?

11.6 Linking

Unless intentionally referring to the latest document in a series, always refer to specific W3C documents by using the "this version" URI.
If you are referring to a W3C document using either its this version or latest version URI, note whether the URI ends in a slash or not. These identifiers do not end in an extension such as ".html". Include the extension when intentionally referring to a specific version (e.g., a GIF image where GIF and PNG are both available through content negotiation).
Visible URIs and href attributes should have the same value.

11.7 Using Examples

Domains in examples adhere to section 3, "Reserved Example Second Level Domain Names," in RFC 2606 [DOMAINS]. Use the domains example.com, example.org, and example.net for all examples. The Internet Assigned Numbers Authority (IANA) reserves them for this purpose. If you need an evocative name or the name of a business, use a machine name (e.g., http://cats.example.org).
When not addressed by second level example domains, top level domains (TLDs) adhere to section 2, "TLDs for Testing, & Documentation Examples," in RFC 2606 [DOMAINS]. Use .test, .example, .invalid or .localhost.
Remember to validate markup in examples. Escaped characters pass through routine validation.
W3C publications are copyrighted by W3C, and W3C liability, trademark and document use rules apply. Note that in general, one should not use material (text, photo, audio) in examples when the copyright is not held by W3C. If the group wishes to publish copyrighted materials, it should contact the Team legal staff.
Use CSS with div elements to mark up examples, as is done in the XML Schema primer ([SCHEMA-PRIMER], section 4.2):
Example
```
background-color: #d5dee3
```
Some XML-related specifications such as XML 1.0 ([XML1], section 2.5) use table elements to achieve this visual effect. This is less desirable than using CSS.
bgcolor="#99ffff"

11.8 Images

We recommend that each image be available as PNG, even if you use content negotiation to serve alternative formats.
Give images a background color (e.g., white) so your technical report can be read with any style sheet (e.g., with W3C's dark on light style sheets, or a user style sheet that specifies a dark background).
Match image size to markup width and height (or images will be distorted).
See the Web Content Accessibility Guidelines Techniques for information about providing alternative text (alt) and long descriptions (longdesc) for images. Also, don't forget to spell-check your alternative text.

11.9 Markup

Use markup as it is intended. The blockquote and ul and li elements were designed for quotations and lists and not for indentation. Use CSS instead.
Remove extraneous non-breaking spaces.
Mark up attributes and elements consistently.
Make sure there are no font or basefont elements in your document.
Make sure all table elements in your document are real data tables, not tables used for layout.
Make sure there are no bgcolor, background, color, face, marginheight, marginwidth or size attributes.
Give each page lang="en-US" on the html element for HTML, or xml:lang="en-US" lang="en-US" on the html element for XHTML 1.0.
Use the span element and lang and xml:lang attributes for language changes within a page.
Make semantic distinctions using more than only color, for example, a font-style change, so that color-blind individuals can see a difference.
Links with the anchor text "Click here" provide no context. The visitor may become lost not knowing where "here" is. See also Don't use "click here" as link text [CLICK-HERE].
Mark up data table headers with th not by bolding a td.

11.10 Large Documents

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

Divide the document logically, storing chapters in separate files.
Offer a single-page, printable, searchable version of the specification. This format may be compressed if large.
You can offer an archived version (zip, tar, tgz) of the separate files. Provide all necessary file in archived versions including the relevant style sheets. Don't link to images or style sheets not included in the archive.

12. Internet Media Types

For information about defining a new Internet media type (formerly known as MIME type) in your specification, see How to Register an Internet Media Type for a W3C Specification [REGISTER-1].
For information about referring to existing Internet media types (registered or not), see the email message TAG Position on Use of Unregistered Media Types in W3C Recommendations [REGISTER-2].

13. 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
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
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: always capitalize
Webmaster: one word, capitalized
Web page: two words, capitalize Web
Web site: two words, capitalize Web (see [GRM])
well-formed: hyphenate
white space: two words
worldwide: one word
World Wide Web: three words, no hyphen
W3C Note: not W3C NOTE

14. 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:

All affiliated with W3C at the time, Dan Connolly, Ian Jacobs, Joseph Reagle, Tim Berners-Lee, Karen MacArthur, and Håkon Wium Lie wrote the majority of this guide in various incarnations since it started in 1995.
Charles McCathieNevile (W3C), Bob Hopgood (Oxford Brookes University), Björn Höhrmann, Paul Grosso (Arbortext), Daniel Dardailler (W3C), Steven Pemberton (W3C), Richard Ishida (Xerox), Martin Dürst (W3C), Mark Davis, Hugo Haas (W3C), Dominique Hazaël-Massieux (W3C), Max Froumentin (W3C), Judy Brewer (W3C), Stuart Williams (Hewlett-Packard), François Yergeau (Alis Technologies), and David Carlisle contributed valuable comments.

15. 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 http://www.w3.org/2002/01/tr-automation/tr-biblio-ui.
[CHARMOD]: Character Model for the World Wide Web 1.0: Fundamentals, M. Dürst, F. Yergeau, R. Ishida, M. Wolf, and T. Texin, Editors. W3C work in progress, 2004. This version of the Character Model Fundamentals is http://www.w3.org/TR/2004/WD-charmod-20040225/. The latest version of the Character Model Fundamentals is available at http://www.w3.org/TR/charmod.
[CHARNAMES]: Unicode character names, M. Davis, M. Dürst, et al., 25-27 August 2001. This email thread is on-line at http://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.
[CHECKLINK]: W3C Link Checker, W3C QA Activity, 2000-2004. This service is on-line at http://www.w3.org/2000/07/checklink.
[CLICK-HERE]: Don't use "click here" as link text, Aaron Swartz. W3C QA Team, 2001. This QA tip is on-line at http://www.w3.org/QA/Tips/noClickHere.
[CSSVALIDATE]: W3C CSS Validation Service, W3C QA Activity, 1997-2004. This service is on-line at http://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 http://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 http://www.w3.org/2003/Editors/.
[EVALUATE]: Evaluating Web Sites for Accessibility, This list of tools for evaluating Web sites for accessibility is on-line at http://www.w3.org/WAI/eval/.
[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 http://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 http://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, I. Jacobs, Editor. W3C, 5 February 2004. The latest version of this document is http://www.w3.org/Consortium/Process.
[PRONOUNS]: Personal pronouns in specifications, M. Dürst, 13 May 2000. This email message is http://lists.w3.org/Archives/Public/www-international/2000AprJun/0058.
[PUBRULES]: Technical Report Publication Policy, I. Jacobs, and the W3C Team. W3C, 2000-2006. This document is on-line at http://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 http://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 http://www.w3.org/2002/06/registering-mediatype.
[REGISTER-2]: TAG Position on Use of Unregistered Media Types in W3C Recommendations, N. Mendelsohn, 4 August 2006. This email message is http://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 http://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 http://www.w3.org/Provider/Style.
[TR]: W3C Technical Reports and Publications, W3C, 1995-2001. This Web page is on-line at http://www.w3.org/TR.
[TRANSLATE]: Translations at W3C, W3C, 1997-2003. This Web page is on-line at http://www.w3.org/Consortium/Translation.
[UNICODE]: Citations and References, The Unicode Consortium, 2001. These instructions for citing Unicode are on-line at http://www.unicode.org/unicode/standard/versions/.
[VALIDATE]: W3C Markup Validation Service, W3C QA Activity, 1997-2004. This service is on-line at http://validator.w3.org.
[WCAG]: Web Content Accessibility Guidelines 1.0, W. Chisholm, G. Vanderheiden, and I. Jacobs, Editors. W3C, 1999. This version of the WCAG Recommendation is http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990505. The latest version of WCAG is available at http://www.w3.org/TR/WAI-WEBCONTENT.
[XHTML1]: XHTML^TM 1.0: The Extensible HyperText Markup Language, S. Pemberton et al. W3C, 2000. This version of XHTML is http://www.w3.org/TR/2000/REC-xhtml1-20000126. The latest version of XHTML1 is available at http://www.w3.org/TR/xhtml1.
[XMLSPEC]: Guide to the W3C XML Specification ("XMLspec") DTD, Version 2.1, E. Maler, Editor. W3C, 1997-2001. This documentation is on-line at http://www.w3.org/XML/1998/06/xmlspec-report-v21. The DTD is on-line at http://www.w3.org/XML/1998/06/xmlspec-v21.dtd.
[XSLT]: XSLT style sheets, N. Walsh et al. 2000-2001. These XSLT stylesheets for XMLspec are on-line at http://dev.w3.org/cvsweb/spec-prod/html.

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 13.3.2, B. Bos, H. W. Lie, C. Lilley, and I. Jacobs, Editors. W3C, 1998. This example is on-line at http://www.w3.org/TR/1998/REC-CSS2-19980512/page.html#named-pages.
[EXCAL]: Excalibur, R. Zaccone, 2001. The Excalibur home page is http://www.eg.bucknell.edu/~excalibr/excalibur.html.
[HTML]: Introducing HTML 3.2. W3C, 1996-1999. This example is on-line at http://www.w3.org/MarkUp/Wilbur.
[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.
[P3PFAQ]: P3P and Privacy on the Web FAQ. W3C, 2000-2001. This example is on-line at http://www.w3.org/P3P/p3pfaq.
[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 http://www.w3.org/TR/xmlschema-2.
[SCHEMA-PRIMER]: XML Schema Part 0: Primer section 4.2, D. Fallside, Editor. W3C, 2001. This example is on-line at http://www.w3.org/TR/2001/REC-xmlschema-0-20010502/#DerivExt.
[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 http://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/.

16. Change History

2001-09-25: Added this change history. Added link to interoperability report in Status section of Candidate Recommendations and later. Removed IPR sentence in editor's role. Added commas after e.g. and i.e. to match US usage. Added chapter 10 on production. Added XMLspec and XSLT references.
2001-10-27: Removed most CSS. Responding to Björn Höhrmann's comments: Added note to not use "you." Fixed references markup. Mentioned two free spelling tools. Now say that filename extensions are permitted when linking to a specific version. Corrected alt text note to say that the text should replace the image when possible. Added xml:lang attribute to 11.8. Clarified reasoning behind not using "click here." Added to description of archived versions.
2001-10-31: Moved punctuation from miscellaneous to a separate section
2002-03-19: Removed border and pencil photo
2002-03-31:
- Removed conformance requirements
- Made links to RFCs FTP per RFC Editor
- Many editorial corrections thanks to Martin Dürst
- Clarified reference links like [XML]
- Added abbr and acronym elements and title attributes throughout
- Added cite throughout
- Added W3C Web team to 8.3. Added commas between email addresses
- Removed links to old copyright release form and Member Agreements
- Added subtitle
- Changed INRIA from abbr to acronym
- Removed some wording about errata
2002-04-29:
- Changed "Acknowledgements" to "Acknowledgments"
- Reversed order of References and Acknowledgments in 9
- Clarified acronyms and initialisms in 11.5
- Changed "XHTML" to "XHTML 1.0" in 11.9
2002-05-23:
- Added style for dates to I18n
- Added image of editor's pencil
2002-07-01:
- Capitalized Process Document in 11.4
2003-01-06:
- Added Web terms to 12
2003-02-11:
- Removed sections covered in pubrules [PUBRULES]
- Added ,spell comma tool
- Removed the former section number 2, Conformance
- Removed the former section number 8, The Publishing Process
- Renumbered chapters
- Added "schemas" to word list
- Removed "must" statements
- Removed most "should" statements
- Added year to date example
- Corrected numbering in Linking from Within
2003-04-02:
- Fixed typo in 9.7
2003-06-30:
- Added to 4.2 Translations
- Added links to the Process Document and to pubrules
- Deleted IPR (section 5)
- Split Help section between Status and section 7
- Moved 7.1.1 Document Title to 7.1, removed 7.1 Head
- Removed 7.1.2 Document Identification, 7.1.3 Alternative Formats, 7.1.4 Editors, Authors, and Contributors, 7.1.5 Copyright Notice, 7.4 Acknowledgments, and much of 7.3 Status Section
- Removed P3P Note from References
- Split 7.5 References into sections
- Removed 9.7 RFCs
- Split 9.7 RFC 2119 Key Words into its own section
- Moved RFC 2606 and example markup to new section 9.8 Using Examples
- Replaced 9.8 Appearance with section on Images
- Added Persistence Policy reference
- Added "Click Here" reference
- Added Editors home page
- Renumbered
2003-11-08 to 09:
- Added 7.1 Bibliography Extractor and renumbered section 7
2004-04-02:
- Update for new Process Document, Character Model Fundamentals, and link to QA Tip
2004-08-02:
- Added TLDs to 11.7
2004-09-02:
- Updated copyright references
- Updated W3C validation services
- Added cites
2005-01-20:
- Changed RFC URIs from rfc-editor.org to ietf.org and from FTP to HTTP
2005-02-07:
- Added note on copyright to 11.7
2005-02-08:
- Added to example reference link in 7.2
2005-05-19:
- Silent on trailing slashes in 11.6
- Also in 11.6, note on URI and href values.
2005-08-17:
- Added notes on custom paragraph to 5.4.
2005-09-08:
- Added note on image formats (use of PNG) to 11.8.
- Added PLURAL reference to 14 and plurals of acronyms and abbreviations to 11.2 and 12.
- Replaced specifics about alt/longdesc with link to WCAG 2.0 techniques.
2006-01-30:
- Added pubrules CSS and navigation
- Updated link to Technical Report Publication Policy (pubrules)
2006-03-27:
- Remove unused references
2006-08-10:
- number sign and hash in 12.
2006-09-14:
- Added 12. Internet Media Types, renumbered
2006-09-29:
- XML updated to fourth edition, replaced HTML reference example with XML, added XML reference
2007-01-11:
- Added business names to 11.7
2007-05-01:
- Added "at least the first occurrence" in 7.2

17. To Do List

2002-03-31:
- Add Dublin Core and RDF.
- Add elementName and attributeName classes to base style sheet.
- Address one-page and multiple-page versions in 7.1.3.
- Add boilerplate for Recommendations to 7.3.
- Address references to parts of a technical report in 7.5.

Ian Jacobs, W3C

Last modified: $Date: 2007/11/15 20:34:27 $

Copyright © 1995-2007 W3C^® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply. Your interactions with this site are in accordance with our public and Member privacy statements.