index.html 27.9 KB

Raw Blame History Permalink

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN">

<html lang=en-US>
 <head>
  <title>HTML Design Principles</title>

  <style type="text/css">
      .example { padding-left: 1em; border-left: 3px solid green }
      .note { font-style: italic; }
      dfn { font-style:normal; font-weight:bold }
      code { color:orangered }
      code :link, code :visited { color:inherit }
      pre code { color:inherit }
    </style>
  <link href="http://www.w3.org/StyleSheets/TR/W3C-WD" rel=stylesheet>

 <body>
  <div class=head>
   <p><a href="http://www.w3.org/"><img alt=W3C height=48
    src="http://www.w3.org/Icons/w3c_home" width=72></a></p>

   <h1 id=html-design-principles>HTML Design Principles</h1>

   <h2 class="no-num no-toc" id=w3c-doctype>W3C Working Draft 26 November
    2007</h2>

   <dl>
    <dt>This Version:</dt>
    <!--<dd>$Revision: 1.1 $ of $Date: 2007/11/26 10:46:03 $
        (<a href="http://dev.w3.org/cvsweb/html5/html-design-principles/Overview.html">revision
        log</a>)</dd>-->

    <dd><a
     href="http://www.w3.org/TR/2007/WD-html-design-principles-20071126/">http://www.w3.org/TR/2007/WD-html-design-principles-20071126/</a>

    <dt>Latest Version:</dt>
    <!--<dd><a href="http://www.w3.org/html/wg/html5/principles/">http://www.w3.org/html/wg/html5/principles/</a></li>-->

    <dd><a
     href="http://www.w3.org/TR/html-design-principles/">http://www.w3.org/TR/html-design-principles/</a>

    <dt>Editors:

    <dd><a href="http://annevankesteren.nl/">Anne van Kesteren</a> (<a
     href="http://www.opera.com/">Opera Software ASA</a>) &lt;<a
     href="mailto:annevk@opera.com">annevk@opera.com</a>>

    <dd>Maciej Stachowiak (<a href="http://www.apple.com/">Apple Inc</a>)
     &lt;<a href="mailto:mjs@apple.com">mjs@apple.com</a>>
   </dl>

   <p class=copyright><a
    href="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyright</a>
    &copy; 2007 <a href="http://www.w3.org/"><abbr title="World Wide Web
    Consortium">W3C</abbr></a><sup>&reg;</sup> (<a
    href="http://www.csail.mit.edu/"><abbr title="Massachusetts Institute of
    Technology">MIT</abbr></a>, <a href="http://www.ercim.org/"><abbr
    title="European Research Consortium for Informatics and
    Mathematics">ERCIM</abbr></a>, <a
    href="http://www.keio.ac.jp/">Keio</a>), All Rights Reserved. W3C <a
    href="http://www.w3.org/Consortium/Legal/ipr-notice#Legal_Disclaimer">liability</a>,
    <a
    href="http://www.w3.org/Consortium/Legal/ipr-notice#W3C_Trademarks">trademark</a>
    and <a
    href="http://www.w3.org/Consortium/Legal/copyright-documents">document
    use</a> rules apply.</p>
  </div>

  <hr>

  <h2 class="no-num no-toc" id=abstract>Abstract</h2>

  <p>HTML&nbsp;5 defines the fifth major revision of the core language of the
   World Wide Web, HTML. This document describes the set of guiding
   principles used by the HTML Working Group for the development of HTML5.
   The principles offer guidance for the design of HTML in the areas of
   compatibility, utility and interoperability.

  <h2 class="no-num no-toc" id=sotd>Status of this Document</h2>

  <p><em>This section describes the status of this document at the time of
   its publication. Other documents may supersede this document. A list of
   current W3C publications and the latest revision of this technical report
   can be found in the <a href="http://www.w3.org/TR/">W3C technical reports
   index</a> at http://www.w3.org/TR/.</em>

  <p>This document is the First Public Working Draft of "HTML Design
   Principles" produced by the <a href="http://www.w3.org/html/wg/">HTML
   Working Group</a>, part of the <a
   href="http://www.w3.org/MarkUp/Activity">HTML Activity</a>. The Working
   Group intends to publish this document as a <a
   href="http://www.w3.org/2005/10/Process-20051014/#WGNote">Working Group
   Note</a>. The working group is working on a new version of HTML not yet
   published under TR. In the meantime, you can access the <a
   href="http://www.w3.org/html/wg/html5/">HTML&nbsp;5 Editor's draft</a>.
   The appropriate forum for comments on this document is <a
   href="mailto:public-html-comments@w3.org">public-html-comments@w3.org</a>,
   a mailing list with a <a
   href="http://lists.w3.org/Archives/Public/public-html-comments/"
   title="Archive for HTML comments mailing-list">public archive</a>.

  <p>The decision to request publication of the document was based on a <a
   href="http://www.w3.org/2002/09/wbs/40318/wdhdp/results">poll of the
   members of the HTML working group</a>, with the results being 51 "Yes"
   votes, 2 "No" votes, and 1 "Formally Object", vote.

  <p>The specific objection recorded was judged to fall under the category of
   a comment that can be addressed in future drafts &mdash; not a critical
   reason to delay publication, and with the understanding that full
   consensus is not a prerequisite to publication, because the decision of
   the HTML working group to publish the document reflects the intent of the
   group to signal to the community to begin carefully reviewing the
   document, and to encourage wide review of the document within and outside
   of W3C.

  <p>Publication as a Working Draft does not imply endorsement by the W3C
   Membership. This is a draft document and may be updated, replaced or
   obsoleted by other documents at any time. It is inappropriate to cite this
   document as other than work in progress.

  <p>This document was produced by a group operating under the <a
   href="http://www.w3.org/Consortium/Patent-Policy-20040205/">5 February
   2004 W3C Patent Policy</a>. The group does not expect this document to
   become a W3C Recommendation. W3C maintains a <a
   href="http://www.w3.org/2004/01/pp-impl/40318/status"
   rel=disclosure>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="http://www.w3.org/Consortium/Patent-Policy-20040205/#def-essential">Essential
   Claim(s)</a> must disclose the information in accordance with <a
   href="http://www.w3.org/Consortium/Patent-Policy-20040205/#sec-Disclosure">section
   6 of the W3C Patent Policy</a>.

  <h2 class="no-num no-toc" id=toc>Table of Contents</h2>
  <!--begin-toc-->

  <ul class=toc>
   <li><a href="#introduction"><span class=secno>1. </span>Introduction</a>
    <ul class=toc>
     <li><a href="#conformance"><span class=secno>1.1. </span>Conformance for
      Documents and Implementations</a>
    </ul>

   <li><a href="#compatibility"><span class=secno>2. </span>Compatibility</a>

    <ul class=toc>
     <li><a href="#support-existing-content"><span class=secno>2.1.
      </span>Support Existing Content</a>
      <ul class=toc>
       <li><a href="#examples"><span class=secno>2.1.1. </span>Examples</a>
      </ul>

     <li><a href="#degrade-gracefully"><span class=secno>2.2. </span>Degrade
      Gracefully</a>
      <ul class=toc>
       <li><a href="#examples0"><span class=secno>2.2.1. </span>Examples</a>
      </ul>

     <li><a href="#do-not-reinvent-the-wheel"><span class=secno>2.3.
      </span>Do not Reinvent the Wheel</a>

     <li><a href="#pave-the-cowpaths"><span class=secno>2.4. </span>Pave the
      Cowpaths</a>

     <li><a href="#evolution-not-revolution"><span class=secno>2.5.
      </span>Evolution Not Revolution</a>
    </ul>

   <li><a href="#utility"><span class=secno>3. </span>Utility</a>
    <ul class=toc>
     <li><a href="#solve-real-problems"><span class=secno>3.1. </span>Solve
      Real Problems</a>

     <li><a href="#priority-of-constituencies"><span class=secno>3.2.
      </span>Priority of Constituencies</a>

     <li><a href="#secure-by-design"><span class=secno>3.3. </span>Secure By
      Design</a>

     <li><a href="#separation-of-concerns"><span class=secno>3.4.
      </span>Separation of Concerns</a>

     <li><a href="#dom-consistency"><span class=secno>3.5. </span>DOM
      Consistency</a>
    </ul>

   <li><a href="#interoperability"><span class=secno>4.
    </span>Interoperability</a>
    <ul class=toc>
     <li><a href="#well-defined-behavior"><span class=secno>4.1.
      </span>Well-defined Behavior</a>

     <li><a href="#avoid-needless-complexity"><span class=secno>4.2.
      </span>Avoid Needless Complexity</a>

     <li><a href="#handle-errors"><span class=secno>4.3. </span>Handle
      Errors</a>
    </ul>

   <li><a href="#universal-access"><span class=secno>5. </span>Universal
    Access</a>
    <ul class=toc>
     <li><a href="#media-independence"><span class=secno>5.1. </span>Media
      Independence</a>

     <li><a href="#support-world-languages"><span class=secno>5.2.
      </span>Support World Languages</a>

     <li><a href="#accessibility"><span class=secno>5.3.
      </span>Accessibility</a>
    </ul>

   <li class=no-num><a href="#acknowledgments">Acknowledgments</a>
  </ul>
  <!--end-toc-->

  <h2 id=introduction><span class=secno>1. </span>Introduction</h2>

  <p>In the HTML Working Group, we have representatives from many different
   communities, including the WHATWG and other W3C Working Groups. The
   HTML&nbsp;5 effort under WHATWG, and much of the work on various W3C
   standards over the past few years, have been based on different goals and
   different ideas of what makes for good design. To make useful progress, we
   need to have some basic agreement on goals for this group.

  <p>These design principles are an attempt to capture consensus on design
   approach. They are pragmatic rules of thumb that must be balanced against
   each other, not absolutes. They are similar in spirit to the TAG's
   findings in Architecture of the World Wide Web, but specific to the
   deliverables of this group.

  <h3 id=conformance><span class=secno>1.1. </span>Conformance for Documents
   and Implementations</h3>

  <p>Many language specifications define a set of conformance requirements
   for valid documents, and corresponding conformance requirements for
   implementations processing these valid documents. HTML&nbsp;5 is somewhat
   unusual in also defining implementation conformance requirements for many
   constructs that are not allowed in conforming documents.

  <p>This dual nature of the spec allows us to have a relatively clean and
   understandable language for authors, while at the same time supporting
   existing documents that make use of older or nonstandard constructs, and
   enabling better interoperability in error handling.

  <p>Some of the design principles below apply much more to the conformance
   requirements for content (the "conforming language") while others apply
   much more to the conformance requirements for implementations (the
   "supported language"). Since the supported language is a strict superset
   of the conforming language, there is considerable overlap, but the
   principles will do their best to make clear which set of requirements they
   apply to.

  <h2 id=compatibility><span class=secno>2. </span>Compatibility</h2>

  <p>There are many ways of interpreting compatibility. Sometimes the terms
   "backwards compatibility" and "forwards compatibility" are used, but
   sometimes the meaning of those terms can be unclear. The principles in
   this section address different facets of compatibility.

  <h3 id=support-existing-content><span class=secno>2.1. </span>Support
   Existing Content</h3>

  <p class=note>This principle applies primarily to the supported language.

  <p>Existing content often relies upon expected user agent processing and
   behavior to function as intended. Processing requirements should be
   specified to ensure that user agents implementing this specification will
   be able to handle most existing content. In particular, it should be
   possible to process existing HTML documents as HTML&nbsp;5 and get results
   that are compatible with the existing expectations of users and authors,
   based on the behavior of existing browsers. It should be made possible,
   though not necessarily required, to do this without mode switching.

  <p>Content relying on existing browser behavior can take many forms. It may
   rely on elements, attributes or APIs that are part of earlier HTML
   specifications, but not part of HTML&nbsp;5, or on features that are
   entirely proprietary. It may depend on specific error handling rules. In
   rare cases, it may depend on a feature from earlier HTML specifications
   <em>not</em> being implemented as specified.

  <p>When considering changes to legacy features or behavior, relative to
   current implementations and author expectations, the following questions
   should be considered:

  <ul>
   <li>Does a significant quantity of existing content depend on the feature
    or behavior?

   <li>Does any of the dependent content occur on particularly popular
    websites?

   <li>Is the dependent content genuinely intended for consumption, rather
    than occurring solely in test cases or examples?

   <li>Is the dependent content on the public web, rather than found solely
    on internal sites with a controlled user environment?

   <li>Does the dependent content currently work as intended in multiple
    popular user agents, rather than explicitly targeting only one particular
    user agent, or only very old or otherwise unpopular ones?
  </ul>

  <p>The benefit of the proposed change should be weighed against the likely
   cost of breaking content, as measured by these criteria. In some cases, it
   may be desirable to make a nonstandard feature or behavior part of the
   conforming language, if it satisfies a valid use case. However, the fact
   that something is part of the supported language does not by itself mean
   that relying on it is condoned or encouraged.

  <h4 id=examples><span class=secno>2.1.1. </span>Examples</h4>

  <p class=example>Many sites use broken markup, such as badly nested
   elements (<code>&lt;b>a&lt;i>b&lt;/b>c&lt;/i></code>), and both authors
   and users have expectations based on the error handling used by legacy
   user agents. We need to define processing requirements that remain
   compatible with the expected handling of such content.

  <p class=example>Some sites rely on the <code>&lt;u&gt;</code> element
   giving the presentational effect of an underline.

  <h3 id=degrade-gracefully><span class=secno>2.2. </span>Degrade Gracefully</h3>

  <p class=note>This principle applies primarily to the conforming language.

  <p>On the World Wide Web, authors are often reluctant to use new language
   features that cause problems in older user agents, or that do not provide
   some sort of graceful fallback. HTML&nbsp;5 document conformance
   requirements should be designed so that Web content can degrade gracefully
   in older or less capable user agents, even when making use of new
   elements, attributes, APIs and content models.

  <p>It is not necessarily appropriate to consider every Web user agent ever
   made, including even very old versions of browsers or tools that are
   extremely unpopular even in their niche markets. However, strong
   consideration should be given to the following categories of user agents.
   It is highly likely that content authors will find it important to target
   these categories:

  <ul>
   <li>Current versions of the top mainstream Web browsers.

   <li>Highly popular older versions of mainstream Web browsers.

   <li>The top user agents designed to meet specific needs or address
    specialized markets, such as assistive technologies, mobile browsers or
    user agents targeting less typical media such as text-only terminals or
    print.
  </ul>

  <p>In some cases, a new feature may simply not apply to a certain class of
   user agents, or may be impractical to design in a way that can degrade.
   For example, new scripting APIs cannot be made to work in scriptless user
   agents. But in many cases, approaches like the following can be used:

  <ul>
   <li>A new element or attribute may provide additional semantics without
    losing essential functionality when not understood.

   <li>A new scripting method or attribute can be tested before use in script
    using ECMAScript introspection facilities.

   <li>A new element or attribute may provide semantics and a simple default
    rendering that can be achieved using CSS, so addition of a small
    stylesheet allows graceful degradation.

   <li>A new element, attribute or scripting API may have behavior that can
    be emulated through the use of additional script, although the scripted
    approach may not provide the same level of performance and convenience.

   <li>A new element may call for a highly specialized rendering, but allow
    different content to be provided as fallback for user agents that do not
    understand the element.
  </ul>

  <p>This list is not exhaustive; in some cases slightly more complicated
   approaches are more effective.

  <h4 id=examples0><span class=secno>2.2.1. </span>Examples</h4>
  <!--
    <p class="example">The default presentation of the
    proposed <code>&lt;section&gt;</code> element can be emulated
    through the CSS rule <code>section { display: block; }</code>.</p>
    -->

  <p class=example>The default presentation of the proposed
   <code>irrelevant</code> attribute can be emulated through the CSS rule
   <code>[irrelevant] { display: none; }</code>.

  <p class=example>Proposed new multimedia elements like <code>&lt;canvas>
   fallback &lt;/canvas></code> or <code>&lt;video> fallback
   &lt;/video></code> allow fallback content. Older user agents will show
   "fallback" while user agents supporting <code>canvas</code> or
   <code>video</code> will show the multimedia content.

  <p class=example>The proposed <code>getElementsByClassName()</code> method
   can be made considerably faster than pure ECMAScript implementations found
   in existing libraries, but a script-based implementation can be used when
   the native version is not available.

  <p class=example>The <code>&lt;datalist></code> element can be associated
   with an <code>&lt;input></code> element and may contain a hidden
   <code>&lt;select></code> element. This way the fallback for the intended
   "combo box" control can be a text field or a text field with an associated
   pop-up menu in existing mainstream browsers

  <h3 id=do-not-reinvent-the-wheel><span class=secno>2.3. </span>Do not
   Reinvent the Wheel</h3>

  <p>If there is already a widely used and implemented technology covering
   particular use cases, consider specifying that technology in preference to
   inventing something new for the same purpose. Sometimes, though, new use
   cases may call for a new approach instead of more extensions on an old
   approach.

  <p class=example><code>contenteditable=""</code> was already used and
   implemented by user agents. No need to invent a new feature.

  <h3 id=pave-the-cowpaths><span class=secno>2.4. </span>Pave the Cowpaths</h3>

  <p>When a practice is already widespread among authors, consider adopting
   it rather than forbidding it or inventing something new.

  <p class=example>Authors already use the <code>&lt;br/></code> syntax as
   opposed to <code>&lt;br></code> in HTML and there is no harm done by
   allowing that to be used.

  <h3 id=evolution-not-revolution><span class=secno>2.5. </span>Evolution Not
   Revolution</h3>

  <p>Revolutions sometimes change the world to the better. Most often,
   however, it is better to evolve an existing design rather than throwing it
   away. This way, authors don't have to learn new models and content will
   live longer. Specifically, this means that one should prefer to design
   features so that old content can take advantage of new features without
   having to make unrelated changes. And implementations should be able to
   add new features to existing code, rather than having to develop whole
   separate modes.

  <p class=example>Switching to XML syntax requires a global change, so
   continue supporting classic HTML syntax as well.

  <h2 id=utility><span class=secno>3. </span>Utility</h2>

  <p>These principles call for a design that makes sure HTML can be used
   effectively for its many intended purposes.

  <h3 id=solve-real-problems><span class=secno>3.1. </span>Solve Real
   Problems</h3>

  <p>Changes to the spec should solve actual real-world problems. Abstract
   architectures that don't address an existing need are less favored than
   pragmatic solutions to problems that web content faces today. And existing
   widespread problems should be solved, when possible.

  <h3 id=priority-of-constituencies><span class=secno>3.2. </span>Priority of
   Constituencies</h3>

  <p>In case of conflict, consider users over authors over implementors over
   specifiers over theoretical purity. In other words costs or difficulties
   to the user should be given more weight than costs to authors; which in
   turn should be given more weight than costs to implementors; which should
   be given more weight than costs to authors of the spec itself, which
   should be given more weight than those proposing changes for theoretical
   reasons alone. Of course, it is preferred to make things better for
   multiple constituencies at once.

  <h3 id=secure-by-design><span class=secno>3.3. </span>Secure By Design</h3>

  <p>Ensure that features work with the security model of the web.
   Preferrably address security considerations directly in the specification.

  <p class=example>Communicating between documents from different sites is
   useful, but an unrestricted version could put user data at risk.
   Cross-document messaging is designed to allow this without violating
   security constraints.

  <h3 id=separation-of-concerns><span class=secno>3.4. </span>Separation of
   Concerns</h3>

  <p>HTML should allow separation of content and presentation. For this
   reason, markup that expresses structure is usually preferred to purely
   presentational markup. However, structural markup is a means to an end
   such as <a href="#media-independence">media independence</a>. Profound and
   detailed semantic encoding is not necessary if the end can be reached
   otherwise. Defining reasonable default presentation for different media
   may be sufficient. HTML strikes a balance between semantic expressiveness
   and practical usefulness. Names of elements and attributes in the markup
   may be pragmatic (for brevity, history, simplicity) rather than completely
   accurate.

  <p class=example>The <code>article</code> element defines an individual
   article, but not the details of how it is displayed. A journal article may
   be the only article on a page, formatted in multiple columns, while a blog
   post may share a page with multiple other articles and be presented in a
   box with a border.

  <p class=example>The <code>b</code> and <code>i</code> elements are widely
   used &mdash; it is better to give them good default rendering for various
   media including aural than to try to ban them.

  <h3 id=dom-consistency><span class=secno>3.5. </span>DOM Consistency</h3>

  <p>The two serializations should be designed in such a way that the DOM
   trees produced by the respective parsers appear as consistently as
   feasible to scripts and other program code operating on the document
   trees. Discrepancies can be allowed for compatibility with legacy
   implementations, but the differences should be minimized.

  <p>Also, unless required for compatibility with legacy implementations and
   deployed content, gratuitous difference in syntactic appearance should be
   avoided as well.

  <p class=example>The HTML (<code>text/html</code>) parser puts elements in
   the <code>http://www.w3.org/1999/xhtml</code> namespace in the DOM for
   compatibility with the XML syntax of HTML&nbsp;5.

  <h2 id=interoperability><span class=secno>4. </span>Interoperability</h2>

  <p>These principles exist to improve the chances of HTML implementations
   being truly interoperable.

  <h3 id=well-defined-behavior><span class=secno>4.1. </span>Well-defined
   Behavior</h3>

  <p>Prefer to clearly define behavior that content authors could rely on, in
   preference to vague or implementation-defined behavior. This way, it is
   easier to author content that works in a variety of user agents. However,
   implementations should still be free to make improvements in areas such as
   user interface and quality of rendering.

  <h3 id=avoid-needless-complexity><span class=secno>4.2. </span>Avoid
   Needless Complexity</h3>

  <p>Simple solutions are preferred to complex ones, when possible. Simpler
   features are easier for user agents to implement, more likely to be
   interoperable, and easier for authors to understand. But this should not
   be used as an excuse to avoid satisfying the other principles.

  <h3 id=handle-errors><span class=secno>4.3. </span>Handle Errors</h3>

  <p>Error handling should be defined so that interoperable implementations
   can be achieved. Prefer graceful error recovery to hard failure, so that
   users are not exposed to authoring errors.

  <h2 id=universal-access><span class=secno>5. </span>Universal Access</h2>

  <p>Features should be designed for universal access. This category covers
   various principles related to that.

  <h3 id=media-independence><span class=secno>5.1. </span>Media Independence</h3>

  <p>Features should, when possible, work across different platforms,
   devices, and media. This should not be taken to mean that a feature should
   be omitted just because some media or platforms can't support it. For
   example, interactive features should not be omitted merely because they
   can not be represented in a printed document.

  <p class=example>The general reflowability of HTML text makes it more
   suitable to variable screen dimensions than a representation of exact
   glyph positions.

  <p class=example>A hyperlink can not be actuated in a printed document, but
   that is no reason to omit the <code>a</code> element.

  <h3 id=support-world-languages><span class=secno>5.2. </span>Support World
   Languages</h3>

  <p>Enable publication in all world languages. But this should not be taken
   as equalizing writing systems by prohibiting features that do not apply to
   all of them. Features for packing multiple translations of a document in a
   single file are out of scope.

  <p class=example>Supporting Unicode allows text in most of the world's
   languages, including mixing of text in different languages.

  <p class=example>Italic text is useful because it applies to many bicameral
   scripts, even though some scripts have no such concept. Similarly, ruby is
   useful for many scripts, even though it has a CJK focus.

  <p class=example>Text in element content has better language support than
   text in attribute content; in element content ruby annotations can be
   inserted, as well as <code>dir</code> attributes and <code>bdo</code>
   elements in case the Unicode bidirectional algorithm is insufficient to
   correctly order adjacent runs of mixed direction text.

  <h3 id=accessibility><span class=secno>5.3. </span>Accessibility</h3>

  <p>Design features to be accessible to users with disabilities. Access by
   everyone regardless of ability is essential. This does not mean that
   features should be omitted entirely if not all users can make full use of
   them, but alternate mechanisms should be provided.

  <p class=example>The image in an <code>img</code> may not be visible to
   blind users, but that is a reason to provide alternate text, not to leave
   out images.

  <p class=example>The <code>progress</code> element is intrinsically
   accessible as it has unambiguous progress bar semantics which permits
   mapping to accessibility APIs that can represent progress indicators.

  <h2 class=no-num id=acknowledgments>Acknowledgments</h2>

  <p>The editors would like to thank Charles McCathieNevile, Chris Wilson,
   Dan Connolly, Henri Sivonen, Ian Hickson, Jirka Kosek, Lachlan Hunt, Nik
   Thierry, Philip Taylor, Richard Ishida, Stephen Stewart, and Steven
   Faulkner for their contributions to this document as well as to all the
   people who have contributed to HTML&nbsp;5 over the years for improving
   the Web!

  <p>If you contributed to this document, but your name is not listed above
   please let the editors know so they can correct this omission.