About · Site map · Github · Help

↑ up to documentation

Publication rules for Recommendation (“REC”)

1. Normative Document Representation

  • § At least one normative representation must be available for requests that use the "This Version" URI. More than one normative representation may be delivered in response to such requests. A "This Version" URI must not be used to identify a non-normative representation.
  • § recursive All normative representations must validate as HTML5 with the following limitations:
    • Inline markup for MathML is permitted but should use a (fallback) alternative.
    • If the HTML5 validator issues content warnings, the publication request must include rationale why the warning is not problematic.
  • § Visual styles should not vary significantly among normative alternatives.

2. Document Metadata

  • § recursive Each document must include the following absolute URI to identify a style sheet for this maturity level: https://www.w3.org/StyleSheets/TR/2021/W3C-REC

    Include this source code:
    <link rel="stylesheet" type="text/css" href="https://www.w3.org/StyleSheets/TR/2021/W3C-REC"/>

  • § recursive Any internal style sheets must be cascaded before this link; i.e., the internal style sheets must not override the W3C tech report styles.
  • § recursive The viewport meta tag is required.

    Include this source code:
    <meta name="viewport" content="width=device-width, initial-scale=1, shrink-to-fit=no">

  • § recursive The canonical link is required.

    Include this source code:
    <link rel="canonical" href="@@URL@@">

3. Front Matter

  • § The front matter must appear at the beginning of the body of the document, within <div class="head">. There is one exception to that requirement: the hr element after the copyright may appear inside or after the div element. Editors should not include other information in this section.
  • § The document's title must be in the title element and in an h1 element. When calculating text equation, special transformations made to h1 are:
    1. Replace ':<br>' with ': '
    2. Replace '<br>' with ' - '
    3. Extract text from h1, and ignore HTML tags.
  • § Technical report version information, i.e., version and edition numbers.
    1. If a Recommendation modified in place, see the Comm Team's policy regarding in-place modification of W3C Technical Reports, otherwise
    2. See the (non-normative) Version Management in W3C Technical Reports for more information.
  • § The document's status and date must be in a <p id="w3c-state"> element as follows (see also date syntax):
    <p id="w3c-state">W3C Recommendation DD Month YYYY</p>

    If this is a modified Recommendation that was modified in place or is a new edition, the document must include both the original publication date and the modification date. For example:

    <p id="w3c-state">W3C Recommendation 7 April 2004, edited in place 19 August2004</p>
  • § Document identifier information must be presented in a dl list, where each dt element marks up an identifier role ("This Version", "Latest Version", "History", etc.) and each dd element includes a link whose link text is the identifier. That dl must itself be placed in a details element.

    Include this source code:
    <details open><summary>More details about this document</summary><dl>...</dl></details>

  • § Document identifier information must be present in this order:
    • 'This version' - URI to that version
    • 'Latest version' - URI to the latest version. See also the (non-normative) Version Management in W3C Technical Reports for information about "latest version" URI and version management.
    • 'History' - URI to the history of the specification
    • Editor(s)
    • Feedback - GitHub repository issue links are required in the <dl>after <dt>Feedback:</dt> in the headers (<div class="head">) of the document. Links are expected to be of the form https://github.com/<USER_OR_ORG>/<REPO_NAME>/[issues|labels][/…].)
    • Errata - URI to an errata document for any errors or issues reported since publication. See also suggestions on errata page structure in the Manual of Style. Note: Do not put the errata document in TR space as the expectation is that we will not modify document in TR space after publication; see the policy for in-place modification of W3C Technical Reports.
  • § The syntax of a “this version” URI must be https://www.w3.org/TR/YYYY/REC-shortname-YYYYMMDD/. If the document introduces a new shortname, it must use lowercase letters.
  • § The title page date and the date at the end of the "This Version" URI must match.
  • § The syntax of a “latest version” URI must be https://www.w3.org/TR/shortname/.
  • § The syntax of a “history” URI must be https://www.w3.org/standards/history/shortname/, and consistent with the shortname mentioned in 'Latest Version'. Note: If there's a shortname change it must be specified using the following data attribute data-previous-shortname='previous-shortname' on the <a> element.
  • § The editors'/authors' names must be listed, with attribute data-editor-id="@@". Affiliations and email addresses are optional; email addresses are not recommended. If an editor/author is acknowledged in an earlier version of this document and the individual's affiliation has since changed, list the individual using the notation "<name>, <affiliation> (until DD Month YYYY)". If the list of authors is very long (e.g., the entire Working Group), identify the authors in the acknowledgments section, linked from the head of the document. Distinguish any contributors from authors in the acknowledgments section.
  • § Authors may provide links to alternative (non-normative) representations or packages for the document. For instance:

    <p>This document is also available in these non-normative formats: <a href="REC-shortname-20180101.html">single HTML file</a>, <a href="REC-shortname-20180101.tgz">gzipped tar file of HTML</a>.</p>

  • § It must include a link to a preliminary interoperability or implementation report.
  • § A horizontal rule (hr) must follow the copyright.

5. Document Status Section

  • § There must be a status section that follows the abstract, labeled with an h2 element with content "Status of This Document". The Team maintains the status section of a document.
  • § It must begin with the following boilerplate text:

    This section describes the status of this document at the time of its publication. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at https://www.w3.org/TR/.

    Include this source code:
    <p><em>This section describes the status of this document at the time of its publication. A list of current W3C publications and the latest revision of this technical report can be found in the <a href="https://www.w3.org/TR/">W3C technical reports index</a> at https://www.w3.org/TR/.</em></p>
  • § All dates must have one of the following forms:
    1. DD Month YYYY : 09 January 2020
    2. DD-Month-YYYY : 09-January-2020
    3. DD Mon YYYY : 09 Jan 2020
    4. DD-Mon-YYYY : 09-Jan-2020
    A leading zero in the day is optional.
  • § It must include the expectations in terms of deployment. The recommended text is:
    W3C recommends the wide deployment of this specification as a standard for the Web.
  • § W3C Recommendation must include one of the following paragraphs in the "Status of This Document" depending on the type of Recommendations:
    1. Recommendation without modifications:
      This document was published by the @@ Working Group as a Recommendation using the Recommendation track.
      Include this source code:
      <p>This document was published by the @@ Working Group as a Recommendation using the <a href="https://www.w3.org/2021/Process-20211102/#recs-and-notes">Recommendation track</a>.</p>
    2. Recommendation with candidate corrections:
      This document was published by the @@ Working Group as a Recommendation using the Recommendation track. It includes candidate corrections.
      Include this source code:
      <p>This document was published by the @@ Working Group as a Recommendation using the <a href="https://www.w3.org/2021/Process-20211102/#recs-and-notes">Recommendation track</a>. It includes <a href="https://www.w3.org/2021/Process-20211102/#candidate-correction">candidate corrections.</a>.</p>
    3. Recommendation with candidate additions:
      This document was published by the @@ Working Group as a Recommendation using the Recommendation track. It includes candidate additions, introducing new features since the Previous Recommendation.
      Include this source code:
      <p>This document was published by the @@ Working Group as a Recommendation using the <a href="https://www.w3.org/2021/Process-20211102/#recs-and-notes">Recommendation track</a>. It includes <a href="https://www.w3.org/2021/Process-20211102/#candidate-addition">candidate additions</a>, introducing new features since the Previous Recommendation.</p>
    4. Recommendation with candidate amendments:
      This document was published by the @@ Working Group as a Recommendation using the Recommendation track. It includes candidate amendments, introducing substantive changes and new features since the Previous Recommendation.
      Include this source code:
      <p>This document was published by the @@ Working Group as a Recommendation using the <a href="https://www.w3.org/2021/Process-20211102/#recs-and-notes">Recommendation track</a>. It includes <a href="https://www.w3.org/2021/Process-20211102/#candidate-amendments">candidate amendments</a>, introducing substantive changes and new features since the Previous Recommendation.</p>
    5. Recommendation with proposed corrections:
      This document was published by the @@ Working Group as a Recommendation using the Recommendation track. It includes proposed corrections.
      Include this source code:
      <p>This document was published by the @@ Working Group as a Recommendation using the <a href="https://www.w3.org/2021/Process-20211102/#recs-and-notes">Recommendation track</a>. It includes <a href="https://www.w3.org/2021/Process-20211102/#proposed-corrections">proposed corrections.</a>.</p>
    6. Recommendation with proposed additions:
      This document was published by the @@ Working Group as a Recommendation using the Recommendation track. It includes proposed additions, introducing new features since the Previous Recommendation.
      Include this source code:
      <p>This document was published by the @@ Working Group as a Recommendation using the <a href="https://www.w3.org/2021/Process-20211102/#recs-and-notes">Recommendation track</a>. It includes <a href="https://www.w3.org/2021/Process-20211102/#proposed-addition">proposed additions</a>, introducing new features since the Previous Recommendation.</p>
    7. Recommendation with proposed amendments:
      This document was published by the @@ Working Group as a Recommendation using the Recommendation track. It includes proposed amendments, introducing substantive changes and new features since the Previous Recommendation.
      Include this source code:
      <p>This document was published by the @@ Working Group as a Recommendation using the <a href="https://www.w3.org/2021/Process-20211102/#recs-and-notes">Recommendation track</a>. It includes <a href="https://www.w3.org/2021/Process-20211102/#proposed-amendments">proposed amendments</a>, introducing substantive changes and new features since the Previous Recommendation.</p>
  • § It must indicate its relationship to previous related Recommendations (e.g., an indication that a Recommendation supersedes, obsoletes, or subsumes another, or that a Recommendation is an editorial revision) and must link to the most recent Recommendation (if any) having the same major revision number. The document thus links to two important resources: the previous edition of the Recommendation via the status section, and the previous draft (the Proposed Recommendation) via the "Previous version" link.
  • § It must include at least one customized paragraph. This section should include the title page date (i.e., the one next to the maturity level at the top of the document). These paragraphs should explain the publication context, including rationale and relationships to other work. See examples and more discussion in the Manual of Style.
  • § It must include a link to changes since the previous draft (e.g., a list of changes or a diff document or both; see the online HTML diff tool).
  • § It must set expectations about the stability of the document. The recommended text is:

    A W3C Recommendation is a specification that, after extensive consensus-building, is endorsed by W3C and its Members, and has commitments from Working Group members to royalty-free licensing for implementations.

    Include this source code:
    <p>A W3C Recommendation is a specification that, after extensive consensus-building, is endorsed by <abbr title="World Wide Web Consortium">W3C</abbr> and its Members, and has commitments from Working Group members to <a href="https://www.w3.org/Consortium/Patent-Policy/#sec-Requirements">royalty-free licensing</a> for implementations.</p>
  • § It must include a text related to the patent policy:
    • if the Working Group is operating under the Patent Policy 2020, the text is:

      This document was produced by a group operating under the W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.

      Include this source code:
      <p>This document was produced by a group operating under the <a href="https://www.w3.org/Consortium/Patent-Policy/">W3C Patent Policy</a>. W3C maintains a <a rel="disclosure" href="@@URI to IPP status or other page@@">public list of any patent disclosures</a> made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains <a href="https://www.w3.org/Consortium/Patent-Policy/#def-essential">Essential Claim(s)</a> must disclose the information in accordance with <a href="https://www.w3.org/Consortium/Patent-Policy/#sec-Disclosure">section 6 of the W3C Patent Policy</a>.</p>
    • if the Working Group is operating under the Patent Policy 2017, the text is:

      This document was produced by a group operating under the 1 August 2017 W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.

      Include this source code:
      <p>This document was produced by a group operating under the <a href="https://www.w3.org/Consortium/Patent-Policy-20170801/">1 August 2017 W3C Patent Policy</a>. W3C maintains a <a rel="disclosure" href="@@URI to IPP status or other page@@">public list of any patent disclosures</a> made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains <a href="https://www.w3.org/Consortium/Patent-Policy-20170801/#def-essential">Essential Claim(s)</a> must disclose the information in accordance with <a href="https://www.w3.org/Consortium/Patent-Policy-20170801/#sec-Disclosure">section 6 of the W3C Patent Policy</a>.</p>
    • if the document is under Note track or Registry track, it must set the licensing requirements related to the Patent Policy. The text is:

      The W3C Patent Policy does not carry any licensing requirements or commitments on this document.

      Include this source code:
      <p>The <a href="https://www.w3.org/Consortium/Patent-Policy/">W3C Patent Policy</a> does not carry any licensing requirements or commitments on this document.</p>

    • if the Note track or Registry track document is published by a Working Group operating under the 2017 W3C Patent Policy, the text is:

      The 1 August 2017 W3C Patent Policy does not carry any licensing requirements or commitments on this document.

      Include this source code:
      <p>The <a href="https://www.w3.org/Consortium/Patent-Policy-20170801/">1 August 2017 W3C Patent Policy</a> does not carry any licensing requirements or commitments on this document.</p>

    Note: Contact the Communications Team for suitable adaptations in the case where a document has been published jointly by more than one group. In the adaptation, be sure that the text for informative-only specs or specs not going to Rec is the same as the standard text.

  • § It must not indicate the number of known disclosures at the time of publication.
  • § If it is the intention to incorporate new features in future updates of the Recommendation, please make sure to identify the document as intending to allow new features. Recommended text is:
    Future updates to this Recommendation may incorporate new features.
    Include one of this source code:
    <p>Future updates to this Recommendation may incorporate <a href="https://www.w3.org/2021/Process-20211102/#allow-new-features">new features</a>.</p>
  • § The document must include the following boilerplate text in the status section to identify the governing process:

    This document is governed by the 2 November 2021 W3C Process Document.

    Include this source code:
    <p>This document is governed by the <a id="w3c_process_revision" href="https://www.w3.org/2021/Process-20211102/">2 November 2021 W3C Process Document</a>. </p>
  • § Modifications in W3C Recommendation are divided into "new features" and "changes". Recommendations with modifications must include the following paragraphs depending on the changes.
    1. proposed corrections, aka "substantive changes":

      there should be a paragraph with class="correction proposed"

      Proposed corrections are marked in the document.
      Include this source code:
      <p class="correction proposed">Proposed corrections are marked in the document.</p>
    2. proposed additions, aka "new features":

      there should be a paragraph with class="addition proposed"

      Proposed additions are marked in the document.
      Include this source code:
      <p class="addition proposed">Proposed additions are marked in the document.</p>
    3. candidate corrections, aka "substantive changes":

      there should be a paragraph with class="correction"

      Candidate corrections are marked in the document.
      Include this source code:
      <p class="correction">Candidate corrections are marked in the document.</p>
    4. candidate additions, aka "new features":

      there should be a paragraph with class="addition"

      Candidate additions are marked in the document.
      Include this source code:
      <p class="correction">Candidate additions are marked in the document.</p>
  • § W3C Recommendation with proposed amendments (substantive changes or new features) must have a comment review date of at least 60 days after the publication date.
    • § There should be a table of contents after the status section, labeled with an h2 element with content "Table of Contents".
    • § The table of content must be inside a navigation element (nav).

      Include this source code:
      <nav id="toc"><h2>Table of Contents</h2>

    7. Document Body

    • § recursive Every marked-up section and subsection of the document must have a target anchor. A section is identified by a heading element (h1-h6). The anchor may be specified using an id (or name if an a element is used) attribute on any of the following: the heading element itself, the parent div or section element of the heading element (where the heading element is the first child of the div or section), a descendant of the heading element, or an a immediately preceding the heading element.
    • § recursive The document must not have any style sheet errors.
    • § recursive All proposed XML namespaces created by the publication of the document must follow URIs for W3C Namespaces .
    • § The document(s) must conform to the Web Content Accessibility Guidelines 2.1, Level AA. Note: You may wish to consult the customizable quick reference to Web Content Accessibility Guidelines 2.1.
    • § The document must include the script fixup.js.

      Include this source code:
      <script src="//www.w3.org/scripts/TR/2021/fixup.js" type="application/javascript"></script>

    8. Compound Documents

    • § If the document is compound (i.e., if it consists of more than one file), all the files must be under a directory /TR/YYYY/REC-shortname-YYYYMMDD/. Exceptions are resources under these paths:
      1. https://www.w3.org/StyleSheets/
      2. https://www.w3.org/scripts/
    • § The main page should be called Overview.html.
    • § All other files must be reachable by links from the document.