[html5] r4876 - [e] (0) Provide rationale for authoring conformance criteria. Fixing http://www. [...]

whatwg at whatwg.org whatwg at whatwg.org
Fri Mar 26 21:44:34 PDT 2010


Author: ianh
Date: 2010-03-26 21:44:32 -0700 (Fri, 26 Mar 2010)
New Revision: 4876

Modified:
   complete.html
   index
   source
Log:
[e] (0) Provide rationale for authoring conformance criteria.
Fixing http://www.w3.org/Bugs/Public/show_bug.cgi?id=7034

Modified: complete.html
===================================================================
--- complete.html	2010-03-27 03:53:19 UTC (rev 4875)
+++ complete.html	2010-03-27 04:44:32 UTC (rev 4876)
@@ -246,7 +246,12 @@
      <li><a href=#how-to-read-this-specification><span class=secno>1.8.1 </span>How to read this specification</a></li>
      <li><a href=#typographic-conventions><span class=secno>1.8.2 </span>Typographic conventions</a></ol></li>
    <li><a href=#a-quick-introduction-to-html><span class=secno>1.9 </span>A quick introduction to HTML</a></li>
-   <li><a href=#recommended-reading><span class=secno>1.10 </span>Recommended reading</a></ol></li>
+   <li><a href=#conformance-requirements-for-authors><span class=secno>1.10 </span>Conformance requirements for authors</a>
+    <ol>
+     <li><a href=#presentational-markup><span class=secno>1.10.1 </span>Presentational markup</a></li>
+     <li><a href=#syntax-errors><span class=secno>1.10.2 </span>Syntax errors</a></li>
+     <li><a href=#restrictions-on-the-content-model-and-on-attribute-values><span class=secno>1.10.3 </span>Restrictions on the content model and on attribute values</a></ol></li>
+   <li><a href=#recommended-reading><span class=secno>1.11 </span>Recommended reading</a></ol></li>
  <li><a href=#infrastructure><span class=secno>2 </span>Common infrastructure</a>
   <ol>
    <li><a href=#terminology><span class=secno>2.1 </span>Terminology</a>
@@ -1876,11 +1881,529 @@
   understand at first.</p>
 
 
+  <h3 id=conformance-requirements-for-authors><span class=secno>1.10 </span>Conformance requirements for authors</h3>
 
-  <h3 id=recommended-reading><span class=secno>1.10 </span>Recommended reading</h3>
+  <p><i>This section is non-normative.</i></p>
 
+  <p>Unlike previous versions of the HTML specification, this
+  specification defines in some detail the required processing for
+  invalid documents as well as valid documents.</p> <!-- This has led
+  to some questioning the purpose of conformance criteria: if there is
+  no ambiguity in how something will be processed, why disallow it? -->
+
+  <p>However, even though the processing of invalid content is in most
+  cases well-defined, conformance requirements for documents are still
+  important: in practice, interoperability (the situation in which all
+  implementations process particular content in a reliable and
+  identical or equivalent way) is not the only goal of document
+  conformance requirements. This section details some of the more
+  common reasons for still distinguishing between a conforming
+  document and one with errors.</p>
+
+
+  <h4 id=presentational-markup><span class=secno>1.10.1 </span>Presentational markup</h4>
+
   <p><i>This section is non-normative.</i></p>
 
+  <p>The majority of presentational features from previous versions of
+  HTML are no longer allowed. Presentational markup in general has
+  been found to have a number of problems:</p>
+
+  <dl><dt>The use of presentational elements leads to poorer accessibility</dt>
+
+   <dd>
+
+    <p>While it is possible to use presentational markup in a way that
+    provides users of assistive technologies (ATs) with an acceptable
+    experience (e.g. using ARIA), doing so is significantly more
+    difficult than doing so when using semantically-appropriate
+    markup. Furthermore, even using such techniques doesn't help make
+    pages accessible for non-AT non-graphical users, such as users of
+    text-mode browsers.</p>
+
+    <p>Using media-independent markup, on the other hand, provides an
+    easy way for documents to be authored in such a way that they work
+    for more users (e.g. text browsers).</p>
+
+   </dd>
+
+
+   <dt>Higher cost of maintenance</dt>
+
+   <dd>
+
+    <p>It is significantly easier to maintain a site written in such a
+    way that the markup is style-independent. For example, changing
+    the colour of a site that uses
+    <code><font color=""></code> throughout requires changes
+    across the entire site, whereas a similar change to a site based
+    on CSS can be done by changing a single file.</p>
+
+   </dd>
+
+
+   <dt>Higher document sizes</dt>
+
+   <dd>
+
+    <p>Presentational markup tends to be much more redundant, and thus
+    results in larger document sizes.</p>
+
+   </dd>
+
+  </dl><p>For those reasons, presentational markup has been removed from
+  HTML in this version. This change should not come as a surprise;
+  HTML4 deprecated presentational markup many years ago and provided a
+  mode (HTML4 Transitional) to help authors move away from
+  presentational markup; later, XHTML 1.1 went further and obsoleted
+  those features altogether.</p>
+
+  <p>The only remaining presentational markup features in HTML are the
+  <code title=attr-style><a href=#the-style-attribute>style</a></code> attribute and the
+  <code><a href=#the-style-element>style</a></code> element. Use of the <code title=attr-style><a href=#the-style-attribute>style</a></code> attribute is somewhat discouraged in
+  production environments, but it can be useful for rapid prototyping
+  (where its rules can be directly moved into a separate style sheet
+  later) and for providing specific styles in unusual cases where a
+  separate style sheet would be inconvenient. Similarly, the
+  <code><a href=#the-style-element>style</a></code> element can be useful in syndication or for
+  page-specific styles, but in general an external style sheet is
+  likely to be more convenient when the styles apply to multiple
+  pages.</p>
+
+  <p>It is also worth noting that four elements that were previously
+  presentational have been redefined in this specification to be
+  media-independent: <code><a href=#the-b-element>b</a></code>, <code><a href=#the-i-element>i</a></code>, <code><a href=#the-hr-element>hr</a></code>,
+  and <code><a href=#the-small-element>small</a></code>.</p>
+
+
+  <h4 id=syntax-errors><span class=secno>1.10.2 </span>Syntax errors</h4>
+
+  <p><i>This section is non-normative.</i></p>
+
+  <p>The syntax of HTML is constrained to avoid a wide variety of
+  problems.</p>
+
+  <dl><dt>Unintuitive error-handling behavior</dt>
+
+   <dd>
+
+    <p>Certain invalid syntax constructs, when parsed, result in DOM
+    trees that are highly unintuitive.</p>
+
+    <div class=example>
+
+     <p>For example, the following markup fragment results in a DOM
+     with an <code><a href=#the-hr-element>hr</a></code> element that is an <em>earlier</em>
+     sibling of the corresponding <code><a href=#the-table-element>table</a></code> element:</p>
+
+     <pre class=bad><table><hr>...</pre>
+
+    </div>
+
+   </dd>
+
+
+   <dt>Errors with optional error recovery</dt>
+
+   <dd>
+
+    <p>To allow user agents to be used in constrolled environments
+    without having to implement the more bizarre and convoluted error
+    handling rules, user agents are permitted to fail whenever
+    encountering a <a href=#parse-error>parse error</a>.</p>
+
+   </dd>
+
+
+   <dt>Errors where the error-handling behavior is not compatible with streaming user agents</dt>
+
+   <dd>
+
+    <p>Some error-handling behavior, such as the behavior for the
+    <code title=""><table><hr>...</code> example mentioned
+    above, are incompatible with streaming user agents. To avoid
+    interoperability problems with such user agents, any syntax
+    resulting in such behavior is considered invalid.</p>
+
+   </dd>
+
+
+   <dt>Errors that can result in infoset coercion</dt>
+
+   <dd>
+
+    <p>When a user agent based on XML is connected to an HTML parser,
+    it is possible that certain invariants that XML enforces, such as
+    comments never containing two consecutive hyphens, will be
+    violated by an HTML file. Handling this can require that the
+    parser coerce the HTML DOM into an XML-compatible infoset. Most
+    syntax constructs that require such handling are considered
+    invalid.</p>
+
+   </dd>
+
+
+   <dt>Errors that result in disproportionally poor performance</dt>
+
+   <dd>
+
+    <p>Certain syntax constructs can result in disproportionally poor
+    performance. To discourage the use of such constructs, they are
+    typically made non-conforming.</p>
+
+    <div class=example>
+
+     <p>For example, the following markup results in poor performance
+     when hitting the highlighted end tag, since all the open elements
+     are examined first to see if they match the close tag:</p>
+
+     <pre class=bad><p><em><span><span><span>...<span><span><span><strong></em></strong></pre>
+
+    </div>
+
+   </dd>
+
+
+   <dt>Errors that help authors avoid fragile syntax constructs</dt>
+
+   <dd>
+
+    <p>There are syntax constructs that, for historical reasons, are
+    relatively fragile. To help reduce the number of users who
+    accidentally run into such problems, they are made
+    non-conforming.</p>
+
+    <div class=example>
+
+     <p>For example, the parsing of certain named character references
+     in attributes happens even with the closing semicolon being
+     omitted. It is safe to include an ampersand followed by letters
+     that do not form a named character reference, but if the letters
+     are changed to a string that <em>does</em> form a named character
+     reference, they will be interpreted as that character instead.</p>
+
+     <p>In this fragment, the attribute's value is "<code title="">?hello=1&world=2</code>":</p>
+
+     <pre class=bad><a href="?hello=1&world=2">Demo</a></pre>
+
+     <p>In the following fragment, however, the attribute's value is
+     actually "<code title="">?original=1©=2</code>",
+     <em>not</em> the intended "<code title="">?original=1&copy=2</code>":</p>
+
+     <pre class=bad><a href="?original=1&copy=2">Compare</a></pre>
+
+     <p>To avoid this problem, all named character references are
+     required to end with a semicolon, and any ampersands followed by
+     letters are required to be escaped.</p>
+
+     <p>Thus, the correct way to express the above cases is as
+     follows:</p>
+
+     <pre><a href="?hello=1&amp;world=2">Demo</a></pre>
+     <pre><a href="?original=1&amp;copy=2">Compare</a></pre>
+
+    </div>
+
+   </dd>
+
+
+   <dt>Errors that flag known interoperability problems in legacy user agents</dt>
+
+   <dd>
+
+    <p>Certain syntax constructs are known to cause especially subtle
+    or serious problems in legacy user agents, and are therefore
+    marked as non-conforming to help authors avoid them.</p>
+
+    <div class=example>
+
+     <p>For example, this is why the U+0060 GRAVE ACCENT character (`)
+     is not allowed in unquoted attributes. In certain legacy user
+     agents, <!-- namely IE --> it is sometimes treated as a quote
+     character.</p>
+
+    </div>
+
+    <div class=example>
+
+     <p>Another example of this is the DOCTYPE, which is required to
+     trigger <a href=#no-quirks-mode>no-quirks mode</a>, because the behavior of
+     legacy user agents in <a href=#quirks-mode>quirks mode</a> is often largely
+     undocumented.</p>
+
+    </div>
+
+   </dd>
+
+
+   <dt>Errors that protect authors from security attacks</dt>
+
+   <dd>
+
+    <p>Certain restrictions exist purely to avoid known security
+    problems.</p>
+
+    <div class=example>
+
+     <p>For example, the restriction on using UTF-7 exists purely to
+     avoid authors falling prey to a known cross-site-scripting attack
+     using UTF-7.</p>
+
+    </div>
+
+   </dd>
+
+
+   <dt>Cases where the author's intent is unclear</dt>
+
+   <dd>
+
+    <p>Some errors merely flag cases where the author's intent is most
+    unclear. Correcting these errors early makes later maintenance easier.</p>
+
+    <div class=example>
+
+     <p>For example, it is unclear whether the author intended the
+     following to be an <code><a href=#the-h1,-h2,-h3,-h4,-h5,-and-h6-elements>h1</a></code> heading or an <code><a href=#the-h1,-h2,-h3,-h4,-h5,-and-h6-elements>h2</a></code>
+     heading:</p>
+
+     <pre class=bad><h1>Contact details</h2></pre>
+
+    </div>
+
+   </dd>
+
+
+   <dt>Cases that are likely to be typos</dt>
+
+   <dd>
+
+    <p>When a user makes a simple typo, it is helpful if the error can
+    be caught early, as this can save the author a lot of debugging
+    time. This specification therefore usually considers it an error
+    to use element names, attribute names, and so forth, that do not
+    match the names defined in this specification.</p>
+
+    <div class=example>
+
+     <p>For example, if the author typed <code><capton></code>
+     instead of <code><caption></code>, this would be flagged as an
+     error and the author could correct the typo immediately.</p>
+
+    </div>
+
+   </dd>
+
+
+   <dt>Errors that allow for new syntax in future</dt>
+
+   <dd>
+
+    <p>In order to allow us to extend the language syntax in the
+    future, certain otherwise harmless features are disallowed.</p>
+
+    <div class=example>
+
+     <p>For example, "attributes" in end tags are ignored currently,
+     but they are invalid, in case a future change to the language
+     makes use of that syntax feature without conflicting with
+     already-deployed (and valid!) content.</p>
+
+    </div>
+
+   </dd>
+
+
+  </dl><p>Some authors find it helpful to be in the practice of always
+  quoting all attributes and always including all optional tags,
+  preferring the consistency derived from such custom over the minor
+  benefits of terseness afforded by making use of the flexibility of
+  the HTML syntax. To aid such authors, conformance checkers can
+  provide modes of operation wherein such conventions are
+  enforced.</p>
+
+
+  <h4 id=restrictions-on-the-content-model-and-on-attribute-values><span class=secno>1.10.3 </span>Restrictions on the content model and on attribute values</h4>
+
+  <p><i>This section is non-normative.</i></p>
+
+  <p>Beyond the syntax of the language, this specification also places
+  restrictions on how elements and attributes can be specified. These
+  restrictions are present for similar reasons:</p>
+
+  <dl><dt>Errors that flag content with dubious semantics</dt>
+
+   <dd>
+
+    <p>To avoid misuse of elements with defined meanings, content
+    models are defined that restrict how elements can be nested when
+    such nestings would be of dubious value.</p>
+
+    <p class=example>For example, this specification disallows
+    nesting a <code><a href=#the-section-element>section</a></code> element inside a <code><a href=#the-kbd-element>kbd</a></code>
+    element, since it is highly unlikely for an author to indicate
+    that an entire section should be keyed in.</p>
+
+   </dd>
+
+
+   <dt>Errors that indicate a conflict in expressed semantics</dt>
+
+   <dd>
+
+    <p>Similarly, to draw the author's attention to mistakes in the
+    use of elements, clear contradictions in the semantics expressed
+    are also considered conformance errors.</p>
+
+    <div class=example>
+
+     <p>In the fragments below, for example, the semantics are
+     nonsensical: a row cannot simultaneously be a cell, nor can a
+     radio button be a progress bar.</p>
+
+     <pre class=bad><tr role="cell"></pre>
+     <pre class=bad><input type=radio role=progressbar></pre>
+
+    </div>
+
+   </dd>
+
+
+   <dt>Errors that encourage a correct understanding of the spec</dt>
+
+   <dd>
+
+    <p>Sometimes, something is disallowed because allowing it would
+    likely cause author confusion.</p>
+
+    <p class=example>For example, setting the <code title=attr-fe-disabled><a href=#attr-fe-disabled>disabled</a></code> attribute to the value
+    "<code title="">false</code>" is disallowed, because despite the
+    appearance of meaning that the element is enabled, it in fact
+    means that the element is <em>disabled</em> (what matters for
+    implementations it the presence of the attribute, not its
+    value).</p>
+
+   </dd>
+
+
+   <dt>Errors that are intended merely to simplify the language</dt>
+
+   <dd>
+
+    <p>Some conformance errors simplify the language that authors need
+    to learn.</p>
+
+    <p class=example>For example, the <code><a href=#the-area-element>area</a></code> element's
+    <code title=attr-area-shape><a href=#attr-area-shape>shape</a></code> attribute, despite
+    accepting both <code title=attr-area-shape-keyword-circ><a href=#attr-area-shape-keyword-circ>circ</a></code> and <code title=attr-area-shape-keyword-circle><a href=#attr-area-shape-keyword-circle>circle</a></code> values in
+    practice as synonyms, disallows the use of the <code title=attr-area-shape-keyword-circ><a href=#attr-area-shape-keyword-circ>circ</a></code> value, so as to
+    simplify tutorials and other learning aids. There would be no
+    benefit to allowing both, but it would cause extra confusion when
+    teaching the language.</p>
+
+   </dd>
+
+
+   <dt>Errors that would likely result in scripts failing in hard-to-debug ways</dt>
+
+   <dd>
+
+    <p>Some errors are intended to help prevent script problems that
+    would be hard to debug.</p>
+
+    <p class=example>This is why, for instance, it is non-conforming
+    to have two <code title=attr-id><a href=#the-id-attribute>id</a></code> attributes with the
+    same value. Duplicate IDs lead to the wrong element being
+    selected, with sometimes disastrous effects whose cause is hard to
+    determine.</p>
+
+   </dd>
+
+
+   <dt>Errors that are intended to save the author time</dt>
+
+   <dd>
+
+    <p>Some constructs are disallowed because historically they have
+    been the cause of a lot of wasted authoring time.</p>
+
+    <p class=example>For example, a <code><a href=#script>script</a></code> element's
+    <code title=attr-script-src><a href=#attr-script-src>src</a></code> attribute causes the
+    element's contents to be ignored. However, this isn't obvious,
+    especially if the element's contents appear to be executable
+    script — which can lead to authors spending a lot of time
+    trying to debug the inlien script without realising that it is not
+    executing. To reduce this problem, this specifications makes it
+    non-conforming to have executable script in a <code><a href=#script>script</a></code>
+    element when the <code title=attr-script-src><a href=#attr-script-src>src</a></code>
+    attribute is present. This means that authors who are validating
+    their documents are less likely to waste time with this kind of
+    mistake.</p>
+
+   </dd>
+
+
+   <dt>Errors that are intended to help authors of polyglot documents</dt>
+
+   <dd>
+
+    <p>Some authors like to write files that can be interpreted as
+    both XML and HTML with similar results. These are known as
+    polyglot documents. Though this practice is discouraged in general
+    due to the myriad of subtle complications involved (especially
+    when involving scripting, styling, or any kind of automated
+    serialization), this specification has a few restrictions intended
+    to at least somewhat mitigate the difficulties.</p>
+
+    <p class=example>For example, there are somewhat complicated
+    rules surrounding the <code title=attr-lang><a href=#attr-lang>lang</a></code> and
+    <code title=attr-xml-lang><a href=#attr-xml-lang>xml:lang</a></code> attributes intended
+    to keep the two synchronized.</p>
+
+    <p class=example>Another example would be the restrictions on
+    the values of <code title="">xmlns</code> attributes in the HTML
+    serialization, which are intended to ensure that elements in
+    conforming polyglot documents end up in the same namespaces
+    whether processed as HTML or XML.</p>
+
+   </dd>
+
+
+   <dt>Errors that reserve space for future expansion</dt>
+
+   <dd>
+
+    <p>As with the restrictions on the syntax intended to allow for
+    new syntax in future revisions of the language, some restrictions
+    on the content models of elements and values of attributes are
+    intended to allow for future expansion of the HTML vocabulary.</p>
+
+    <p class=example>For example, limiting the values of the <code title=attr-hyperlink-target><a href=#attr-hyperlink-target>target</a></code> attribute that start
+    with an U+005F LOW LINE character (_) to only specific predefined
+    values allows new predefined values to be introduced at a future
+    time without conflicting with author-defined values.</p>
+ 
+   </dd>
+
+
+   <dt>Errors that indicate a mis-use of other specifications</dt>
+
+   <dd>
+
+    <p>Certain restrictions are intended to support the restrictions
+    made by other specifications.</p>
+
+    <p class=example>For example, requiring that attributes that
+    take media queries use only <em>valid</em> media queries
+    reinforces the importance of following the conformance rules of
+    that specification.</p>
+
+   </dd>
+
+  </dl><h3 id=recommended-reading><span class=secno>1.11 </span>Recommended reading</h3>
+
+  <p><i>This section is non-normative.</i></p>
+
   <p>The following documents might be of interest to readers of this
   specification.</p>
 

Modified: index
===================================================================
--- index	2010-03-27 03:53:19 UTC (rev 4875)
+++ index	2010-03-27 04:44:32 UTC (rev 4876)
@@ -255,7 +255,12 @@
      <li><a href=#how-to-read-this-specification><span class=secno>1.8.1 </span>How to read this specification</a></li>
      <li><a href=#typographic-conventions><span class=secno>1.8.2 </span>Typographic conventions</a></ol></li>
    <li><a href=#a-quick-introduction-to-html><span class=secno>1.9 </span>A quick introduction to HTML</a></li>
-   <li><a href=#recommended-reading><span class=secno>1.10 </span>Recommended reading</a></ol></li>
+   <li><a href=#conformance-requirements-for-authors><span class=secno>1.10 </span>Conformance requirements for authors</a>
+    <ol>
+     <li><a href=#presentational-markup><span class=secno>1.10.1 </span>Presentational markup</a></li>
+     <li><a href=#syntax-errors><span class=secno>1.10.2 </span>Syntax errors</a></li>
+     <li><a href=#restrictions-on-the-content-model-and-on-attribute-values><span class=secno>1.10.3 </span>Restrictions on the content model and on attribute values</a></ol></li>
+   <li><a href=#recommended-reading><span class=secno>1.11 </span>Recommended reading</a></ol></li>
  <li><a href=#infrastructure><span class=secno>2 </span>Common infrastructure</a>
   <ol>
    <li><a href=#terminology><span class=secno>2.1 </span>Terminology</a>
@@ -1774,11 +1779,529 @@
   understand at first.</p>
 
 
+  <h3 id=conformance-requirements-for-authors><span class=secno>1.10 </span>Conformance requirements for authors</h3>
 
-  <h3 id=recommended-reading><span class=secno>1.10 </span>Recommended reading</h3>
+  <p><i>This section is non-normative.</i></p>
 
+  <p>Unlike previous versions of the HTML specification, this
+  specification defines in some detail the required processing for
+  invalid documents as well as valid documents.</p> <!-- This has led
+  to some questioning the purpose of conformance criteria: if there is
+  no ambiguity in how something will be processed, why disallow it? -->
+
+  <p>However, even though the processing of invalid content is in most
+  cases well-defined, conformance requirements for documents are still
+  important: in practice, interoperability (the situation in which all
+  implementations process particular content in a reliable and
+  identical or equivalent way) is not the only goal of document
+  conformance requirements. This section details some of the more
+  common reasons for still distinguishing between a conforming
+  document and one with errors.</p>
+
+
+  <h4 id=presentational-markup><span class=secno>1.10.1 </span>Presentational markup</h4>
+
   <p><i>This section is non-normative.</i></p>
 
+  <p>The majority of presentational features from previous versions of
+  HTML are no longer allowed. Presentational markup in general has
+  been found to have a number of problems:</p>
+
+  <dl><dt>The use of presentational elements leads to poorer accessibility</dt>
+
+   <dd>
+
+    <p>While it is possible to use presentational markup in a way that
+    provides users of assistive technologies (ATs) with an acceptable
+    experience (e.g. using ARIA), doing so is significantly more
+    difficult than doing so when using semantically-appropriate
+    markup. Furthermore, even using such techniques doesn't help make
+    pages accessible for non-AT non-graphical users, such as users of
+    text-mode browsers.</p>
+
+    <p>Using media-independent markup, on the other hand, provides an
+    easy way for documents to be authored in such a way that they work
+    for more users (e.g. text browsers).</p>
+
+   </dd>
+
+
+   <dt>Higher cost of maintenance</dt>
+
+   <dd>
+
+    <p>It is significantly easier to maintain a site written in such a
+    way that the markup is style-independent. For example, changing
+    the colour of a site that uses
+    <code><font color=""></code> throughout requires changes
+    across the entire site, whereas a similar change to a site based
+    on CSS can be done by changing a single file.</p>
+
+   </dd>
+
+
+   <dt>Higher document sizes</dt>
+
+   <dd>
+
+    <p>Presentational markup tends to be much more redundant, and thus
+    results in larger document sizes.</p>
+
+   </dd>
+
+  </dl><p>For those reasons, presentational markup has been removed from
+  HTML in this version. This change should not come as a surprise;
+  HTML4 deprecated presentational markup many years ago and provided a
+  mode (HTML4 Transitional) to help authors move away from
+  presentational markup; later, XHTML 1.1 went further and obsoleted
+  those features altogether.</p>
+
+  <p>The only remaining presentational markup features in HTML are the
+  <code title=attr-style><a href=#the-style-attribute>style</a></code> attribute and the
+  <code><a href=#the-style-element>style</a></code> element. Use of the <code title=attr-style><a href=#the-style-attribute>style</a></code> attribute is somewhat discouraged in
+  production environments, but it can be useful for rapid prototyping
+  (where its rules can be directly moved into a separate style sheet
+  later) and for providing specific styles in unusual cases where a
+  separate style sheet would be inconvenient. Similarly, the
+  <code><a href=#the-style-element>style</a></code> element can be useful in syndication or for
+  page-specific styles, but in general an external style sheet is
+  likely to be more convenient when the styles apply to multiple
+  pages.</p>
+
+  <p>It is also worth noting that four elements that were previously
+  presentational have been redefined in this specification to be
+  media-independent: <code><a href=#the-b-element>b</a></code>, <code><a href=#the-i-element>i</a></code>, <code><a href=#the-hr-element>hr</a></code>,
+  and <code><a href=#the-small-element>small</a></code>.</p>
+
+
+  <h4 id=syntax-errors><span class=secno>1.10.2 </span>Syntax errors</h4>
+
+  <p><i>This section is non-normative.</i></p>
+
+  <p>The syntax of HTML is constrained to avoid a wide variety of
+  problems.</p>
+
+  <dl><dt>Unintuitive error-handling behavior</dt>
+
+   <dd>
+
+    <p>Certain invalid syntax constructs, when parsed, result in DOM
+    trees that are highly unintuitive.</p>
+
+    <div class=example>
+
+     <p>For example, the following markup fragment results in a DOM
+     with an <code><a href=#the-hr-element>hr</a></code> element that is an <em>earlier</em>
+     sibling of the corresponding <code><a href=#the-table-element>table</a></code> element:</p>
+
+     <pre class=bad><table><hr>...</pre>
+
+    </div>
+
+   </dd>
+
+
+   <dt>Errors with optional error recovery</dt>
+
+   <dd>
+
+    <p>To allow user agents to be used in constrolled environments
+    without having to implement the more bizarre and convoluted error
+    handling rules, user agents are permitted to fail whenever
+    encountering a <a href=#parse-error>parse error</a>.</p>
+
+   </dd>
+
+
+   <dt>Errors where the error-handling behavior is not compatible with streaming user agents</dt>
+
+   <dd>
+
+    <p>Some error-handling behavior, such as the behavior for the
+    <code title=""><table><hr>...</code> example mentioned
+    above, are incompatible with streaming user agents. To avoid
+    interoperability problems with such user agents, any syntax
+    resulting in such behavior is considered invalid.</p>
+
+   </dd>
+
+
+   <dt>Errors that can result in infoset coercion</dt>
+
+   <dd>
+
+    <p>When a user agent based on XML is connected to an HTML parser,
+    it is possible that certain invariants that XML enforces, such as
+    comments never containing two consecutive hyphens, will be
+    violated by an HTML file. Handling this can require that the
+    parser coerce the HTML DOM into an XML-compatible infoset. Most
+    syntax constructs that require such handling are considered
+    invalid.</p>
+
+   </dd>
+
+
+   <dt>Errors that result in disproportionally poor performance</dt>
+
+   <dd>
+
+    <p>Certain syntax constructs can result in disproportionally poor
+    performance. To discourage the use of such constructs, they are
+    typically made non-conforming.</p>
+
+    <div class=example>
+
+     <p>For example, the following markup results in poor performance
+     when hitting the highlighted end tag, since all the open elements
+     are examined first to see if they match the close tag:</p>
+
+     <pre class=bad><p><em><span><span><span>...<span><span><span><strong></em></strong></pre>
+
+    </div>
+
+   </dd>
+
+
+   <dt>Errors that help authors avoid fragile syntax constructs</dt>
+
+   <dd>
+
+    <p>There are syntax constructs that, for historical reasons, are
+    relatively fragile. To help reduce the number of users who
+    accidentally run into such problems, they are made
+    non-conforming.</p>
+
+    <div class=example>
+
+     <p>For example, the parsing of certain named character references
+     in attributes happens even with the closing semicolon being
+     omitted. It is safe to include an ampersand followed by letters
+     that do not form a named character reference, but if the letters
+     are changed to a string that <em>does</em> form a named character
+     reference, they will be interpreted as that character instead.</p>
+
+     <p>In this fragment, the attribute's value is "<code title="">?hello=1&world=2</code>":</p>
+
+     <pre class=bad><a href="?hello=1&world=2">Demo</a></pre>
+
+     <p>In the following fragment, however, the attribute's value is
+     actually "<code title="">?original=1©=2</code>",
+     <em>not</em> the intended "<code title="">?original=1&copy=2</code>":</p>
+
+     <pre class=bad><a href="?original=1&copy=2">Compare</a></pre>
+
+     <p>To avoid this problem, all named character references are
+     required to end with a semicolon, and any ampersands followed by
+     letters are required to be escaped.</p>
+
+     <p>Thus, the correct way to express the above cases is as
+     follows:</p>
+
+     <pre><a href="?hello=1&amp;world=2">Demo</a></pre>
+     <pre><a href="?original=1&amp;copy=2">Compare</a></pre>
+
+    </div>
+
+   </dd>
+
+
+   <dt>Errors that flag known interoperability problems in legacy user agents</dt>
+
+   <dd>
+
+    <p>Certain syntax constructs are known to cause especially subtle
+    or serious problems in legacy user agents, and are therefore
+    marked as non-conforming to help authors avoid them.</p>
+
+    <div class=example>
+
+     <p>For example, this is why the U+0060 GRAVE ACCENT character (`)
+     is not allowed in unquoted attributes. In certain legacy user
+     agents, <!-- namely IE --> it is sometimes treated as a quote
+     character.</p>
+
+    </div>
+
+    <div class=example>
+
+     <p>Another example of this is the DOCTYPE, which is required to
+     trigger <a href=#no-quirks-mode>no-quirks mode</a>, because the behavior of
+     legacy user agents in <a href=#quirks-mode>quirks mode</a> is often largely
+     undocumented.</p>
+
+    </div>
+
+   </dd>
+
+
+   <dt>Errors that protect authors from security attacks</dt>
+
+   <dd>
+
+    <p>Certain restrictions exist purely to avoid known security
+    problems.</p>
+
+    <div class=example>
+
+     <p>For example, the restriction on using UTF-7 exists purely to
+     avoid authors falling prey to a known cross-site-scripting attack
+     using UTF-7.</p>
+
+    </div>
+
+   </dd>
+
+
+   <dt>Cases where the author's intent is unclear</dt>
+
+   <dd>
+
+    <p>Some errors merely flag cases where the author's intent is most
+    unclear. Correcting these errors early makes later maintenance easier.</p>
+
+    <div class=example>
+
+     <p>For example, it is unclear whether the author intended the
+     following to be an <code><a href=#the-h1,-h2,-h3,-h4,-h5,-and-h6-elements>h1</a></code> heading or an <code><a href=#the-h1,-h2,-h3,-h4,-h5,-and-h6-elements>h2</a></code>
+     heading:</p>
+
+     <pre class=bad><h1>Contact details</h2></pre>
+
+    </div>
+
+   </dd>
+
+
+   <dt>Cases that are likely to be typos</dt>
+
+   <dd>
+
+    <p>When a user makes a simple typo, it is helpful if the error can
+    be caught early, as this can save the author a lot of debugging
+    time. This specification therefore usually considers it an error
+    to use element names, attribute names, and so forth, that do not
+    match the names defined in this specification.</p>
+
+    <div class=example>
+
+     <p>For example, if the author typed <code><capton></code>
+     instead of <code><caption></code>, this would be flagged as an
+     error and the author could correct the typo immediately.</p>
+
+    </div>
+
+   </dd>
+
+
+   <dt>Errors that allow for new syntax in future</dt>
+
+   <dd>
+
+    <p>In order to allow us to extend the language syntax in the
+    future, certain otherwise harmless features are disallowed.</p>
+
+    <div class=example>
+
+     <p>For example, "attributes" in end tags are ignored currently,
+     but they are invalid, in case a future change to the language
+     makes use of that syntax feature without conflicting with
+     already-deployed (and valid!) content.</p>
+
+    </div>
+
+   </dd>
+
+
+  </dl><p>Some authors find it helpful to be in the practice of always
+  quoting all attributes and always including all optional tags,
+  preferring the consistency derived from such custom over the minor
+  benefits of terseness afforded by making use of the flexibility of
+  the HTML syntax. To aid such authors, conformance checkers can
+  provide modes of operation wherein such conventions are
+  enforced.</p>
+
+
+  <h4 id=restrictions-on-the-content-model-and-on-attribute-values><span class=secno>1.10.3 </span>Restrictions on the content model and on attribute values</h4>
+
+  <p><i>This section is non-normative.</i></p>
+
+  <p>Beyond the syntax of the language, this specification also places
+  restrictions on how elements and attributes can be specified. These
+  restrictions are present for similar reasons:</p>
+
+  <dl><dt>Errors that flag content with dubious semantics</dt>
+
+   <dd>
+
+    <p>To avoid misuse of elements with defined meanings, content
+    models are defined that restrict how elements can be nested when
+    such nestings would be of dubious value.</p>
+
+    <p class=example>For example, this specification disallows
+    nesting a <code><a href=#the-section-element>section</a></code> element inside a <code><a href=#the-kbd-element>kbd</a></code>
+    element, since it is highly unlikely for an author to indicate
+    that an entire section should be keyed in.</p>
+
+   </dd>
+
+
+   <dt>Errors that indicate a conflict in expressed semantics</dt>
+
+   <dd>
+
+    <p>Similarly, to draw the author's attention to mistakes in the
+    use of elements, clear contradictions in the semantics expressed
+    are also considered conformance errors.</p>
+
+    <div class=example>
+
+     <p>In the fragments below, for example, the semantics are
+     nonsensical: a row cannot simultaneously be a cell, nor can a
+     radio button be a progress bar.</p>
+
+     <pre class=bad><tr role="cell"></pre>
+     <pre class=bad><input type=radio role=progressbar></pre>
+
+    </div>
+
+   </dd>
+
+
+   <dt>Errors that encourage a correct understanding of the spec</dt>
+
+   <dd>
+
+    <p>Sometimes, something is disallowed because allowing it would
+    likely cause author confusion.</p>
+
+    <p class=example>For example, setting the <code title=attr-fe-disabled><a href=#attr-fe-disabled>disabled</a></code> attribute to the value
+    "<code title="">false</code>" is disallowed, because despite the
+    appearance of meaning that the element is enabled, it in fact
+    means that the element is <em>disabled</em> (what matters for
+    implementations it the presence of the attribute, not its
+    value).</p>
+
+   </dd>
+
+
+   <dt>Errors that are intended merely to simplify the language</dt>
+
+   <dd>
+
+    <p>Some conformance errors simplify the language that authors need
+    to learn.</p>
+
+    <p class=example>For example, the <code><a href=#the-area-element>area</a></code> element's
+    <code title=attr-area-shape><a href=#attr-area-shape>shape</a></code> attribute, despite
+    accepting both <code title=attr-area-shape-keyword-circ><a href=#attr-area-shape-keyword-circ>circ</a></code> and <code title=attr-area-shape-keyword-circle><a href=#attr-area-shape-keyword-circle>circle</a></code> values in
+    practice as synonyms, disallows the use of the <code title=attr-area-shape-keyword-circ><a href=#attr-area-shape-keyword-circ>circ</a></code> value, so as to
+    simplify tutorials and other learning aids. There would be no
+    benefit to allowing both, but it would cause extra confusion when
+    teaching the language.</p>
+
+   </dd>
+
+
+   <dt>Errors that would likely result in scripts failing in hard-to-debug ways</dt>
+
+   <dd>
+
+    <p>Some errors are intended to help prevent script problems that
+    would be hard to debug.</p>
+
+    <p class=example>This is why, for instance, it is non-conforming
+    to have two <code title=attr-id><a href=#the-id-attribute>id</a></code> attributes with the
+    same value. Duplicate IDs lead to the wrong element being
+    selected, with sometimes disastrous effects whose cause is hard to
+    determine.</p>
+
+   </dd>
+
+
+   <dt>Errors that are intended to save the author time</dt>
+
+   <dd>
+
+    <p>Some constructs are disallowed because historically they have
+    been the cause of a lot of wasted authoring time.</p>
+
+    <p class=example>For example, a <code><a href=#script>script</a></code> element's
+    <code title=attr-script-src><a href=#attr-script-src>src</a></code> attribute causes the
+    element's contents to be ignored. However, this isn't obvious,
+    especially if the element's contents appear to be executable
+    script — which can lead to authors spending a lot of time
+    trying to debug the inlien script without realising that it is not
+    executing. To reduce this problem, this specifications makes it
+    non-conforming to have executable script in a <code><a href=#script>script</a></code>
+    element when the <code title=attr-script-src><a href=#attr-script-src>src</a></code>
+    attribute is present. This means that authors who are validating
+    their documents are less likely to waste time with this kind of
+    mistake.</p>
+
+   </dd>
+
+
+   <dt>Errors that are intended to help authors of polyglot documents</dt>
+
+   <dd>
+
+    <p>Some authors like to write files that can be interpreted as
+    both XML and HTML with similar results. These are known as
+    polyglot documents. Though this practice is discouraged in general
+    due to the myriad of subtle complications involved (especially
+    when involving scripting, styling, or any kind of automated
+    serialization), this specification has a few restrictions intended
+    to at least somewhat mitigate the difficulties.</p>
+
+    <p class=example>For example, there are somewhat complicated
+    rules surrounding the <code title=attr-lang><a href=#attr-lang>lang</a></code> and
+    <code title=attr-xml-lang><a href=#attr-xml-lang>xml:lang</a></code> attributes intended
+    to keep the two synchronized.</p>
+
+    <p class=example>Another example would be the restrictions on
+    the values of <code title="">xmlns</code> attributes in the HTML
+    serialization, which are intended to ensure that elements in
+    conforming polyglot documents end up in the same namespaces
+    whether processed as HTML or XML.</p>
+
+   </dd>
+
+
+   <dt>Errors that reserve space for future expansion</dt>
+
+   <dd>
+
+    <p>As with the restrictions on the syntax intended to allow for
+    new syntax in future revisions of the language, some restrictions
+    on the content models of elements and values of attributes are
+    intended to allow for future expansion of the HTML vocabulary.</p>
+
+    <p class=example>For example, limiting the values of the <code title=attr-hyperlink-target><a href=#attr-hyperlink-target>target</a></code> attribute that start
+    with an U+005F LOW LINE character (_) to only specific predefined
+    values allows new predefined values to be introduced at a future
+    time without conflicting with author-defined values.</p>
+ 
+   </dd>
+
+
+   <dt>Errors that indicate a mis-use of other specifications</dt>
+
+   <dd>
+
+    <p>Certain restrictions are intended to support the restrictions
+    made by other specifications.</p>
+
+    <p class=example>For example, requiring that attributes that
+    take media queries use only <em>valid</em> media queries
+    reinforces the importance of following the conformance rules of
+    that specification.</p>
+
+   </dd>
+
+  </dl><h3 id=recommended-reading><span class=secno>1.11 </span>Recommended reading</h3>
+
+  <p><i>This section is non-normative.</i></p>
+
   <p>The following documents might be of interest to readers of this
   specification.</p>
 

Modified: source
===================================================================
--- source	2010-03-27 03:53:19 UTC (rev 4875)
+++ source	2010-03-27 04:44:32 UTC (rev 4876)
@@ -715,7 +715,548 @@
   understand at first.</p>
 
 
+  <h3>Conformance requirements for authors</h3>
 
+  <p><i>This section is non-normative.</i></p>
+
+  <p>Unlike previous versions of the HTML specification, this
+  specification defines in some detail the required processing for
+  invalid documents as well as valid documents.</p> <!-- This has led
+  to some questioning the purpose of conformance criteria: if there is
+  no ambiguity in how something will be processed, why disallow it? -->
+
+  <p>However, even though the processing of invalid content is in most
+  cases well-defined, conformance requirements for documents are still
+  important: in practice, interoperability (the situation in which all
+  implementations process particular content in a reliable and
+  identical or equivalent way) is not the only goal of document
+  conformance requirements. This section details some of the more
+  common reasons for still distinguishing between a conforming
+  document and one with errors.</p>
+
+
+  <h4>Presentational markup</h4>
+
+  <p><i>This section is non-normative.</i></p>
+
+  <p>The majority of presentational features from previous versions of
+  HTML are no longer allowed. Presentational markup in general has
+  been found to have a number of problems:</p>
+
+  <dl>
+
+   <dt>The use of presentational elements leads to poorer accessibility</dt>
+
+   <dd>
+
+    <p>While it is possible to use presentational markup in a way that
+    provides users of assistive technologies (ATs) with an acceptable
+    experience (e.g. using ARIA), doing so is significantly more
+    difficult than doing so when using semantically-appropriate
+    markup. Furthermore, even using such techniques doesn't help make
+    pages accessible for non-AT non-graphical users, such as users of
+    text-mode browsers.</p>
+
+    <p>Using media-independent markup, on the other hand, provides an
+    easy way for documents to be authored in such a way that they work
+    for more users (e.g. text browsers).</p>
+
+   </dd>
+
+
+   <dt>Higher cost of maintenance</dt>
+
+   <dd>
+
+    <p>It is significantly easier to maintain a site written in such a
+    way that the markup is style-independent. For example, changing
+    the colour of a site that uses
+    <code><font color=""></code> throughout requires changes
+    across the entire site, whereas a similar change to a site based
+    on CSS can be done by changing a single file.</p>
+
+   </dd>
+
+
+   <dt>Higher document sizes</dt>
+
+   <dd>
+
+    <p>Presentational markup tends to be much more redundant, and thus
+    results in larger document sizes.</p>
+
+   </dd>
+
+  </dl>
+
+  <p>For those reasons, presentational markup has been removed from
+  HTML in this version. This change should not come as a surprise;
+  HTML4 deprecated presentational markup many years ago and provided a
+  mode (HTML4 Transitional) to help authors move away from
+  presentational markup; later, XHTML 1.1 went further and obsoleted
+  those features altogether.</p>
+
+  <p>The only remaining presentational markup features in HTML are the
+  <code title="attr-style">style</code> attribute and the
+  <code>style</code> element. Use of the <code
+  title="attr-style">style</code> attribute is somewhat discouraged in
+  production environments, but it can be useful for rapid prototyping
+  (where its rules can be directly moved into a separate style sheet
+  later) and for providing specific styles in unusual cases where a
+  separate style sheet would be inconvenient. Similarly, the
+  <code>style</code> element can be useful in syndication or for
+  page-specific styles, but in general an external style sheet is
+  likely to be more convenient when the styles apply to multiple
+  pages.</p>
+
+  <p>It is also worth noting that four elements that were previously
+  presentational have been redefined in this specification to be
+  media-independent: <code>b</code>, <code>i</code>, <code>hr</code>,
+  and <code>small</code>.</p>
+
+
+  <h4>Syntax errors</h4>
+
+  <p><i>This section is non-normative.</i></p>
+
+  <p>The syntax of HTML is constrained to avoid a wide variety of
+  problems.</p>
+
+  <dl>
+
+   <dt>Unintuitive error-handling behavior</dt>
+
+   <dd>
+
+    <p>Certain invalid syntax constructs, when parsed, result in DOM
+    trees that are highly unintuitive.</p>
+
+    <div class="example">
+
+     <p>For example, the following markup fragment results in a DOM
+     with an <code>hr</code> element that is an <em>earlier</em>
+     sibling of the corresponding <code>table</code> element:</p>
+
+     <pre class="bad"><table><hr>...</pre>
+
+    </div>
+
+   </dd>
+
+
+   <dt>Errors with optional error recovery</dt>
+
+   <dd>
+
+    <p>To allow user agents to be used in constrolled environments
+    without having to implement the more bizarre and convoluted error
+    handling rules, user agents are permitted to fail whenever
+    encountering a <span>parse error</span>.</p>
+
+   </dd>
+
+
+   <dt>Errors where the error-handling behavior is not compatible with streaming user agents</dt>
+
+   <dd>
+
+    <p>Some error-handling behavior, such as the behavior for the
+    <code title=""><table><hr>...</code> example mentioned
+    above, are incompatible with streaming user agents. To avoid
+    interoperability problems with such user agents, any syntax
+    resulting in such behavior is considered invalid.</p>
+
+   </dd>
+
+
+   <dt>Errors that can result in infoset coercion</dt>
+
+   <dd>
+
+    <p>When a user agent based on XML is connected to an HTML parser,
+    it is possible that certain invariants that XML enforces, such as
+    comments never containing two consecutive hyphens, will be
+    violated by an HTML file. Handling this can require that the
+    parser coerce the HTML DOM into an XML-compatible infoset. Most
+    syntax constructs that require such handling are considered
+    invalid.</p>
+
+   </dd>
+
+
+   <dt>Errors that result in disproportionally poor performance</dt>
+
+   <dd>
+
+    <p>Certain syntax constructs can result in disproportionally poor
+    performance. To discourage the use of such constructs, they are
+    typically made non-conforming.</p>
+
+    <div class="example">
+
+     <p>For example, the following markup results in poor performance
+     when hitting the highlighted end tag, since all the open elements
+     are examined first to see if they match the close tag:</p>
+
+     <pre class="bad"><p><em><span><span><span>...<span><span><span><strong></em></strong></pre>
+
+    </div>
+
+   </dd>
+
+
+   <dt>Errors that help authors avoid fragile syntax constructs</dt>
+
+   <dd>
+
+    <p>There are syntax constructs that, for historical reasons, are
+    relatively fragile. To help reduce the number of users who
+    accidentally run into such problems, they are made
+    non-conforming.</p>
+
+    <div class="example">
+
+     <p>For example, the parsing of certain named character references
+     in attributes happens even with the closing semicolon being
+     omitted. It is safe to include an ampersand followed by letters
+     that do not form a named character reference, but if the letters
+     are changed to a string that <em>does</em> form a named character
+     reference, they will be interpreted as that character instead.</p>
+
+     <p>In this fragment, the attribute's value is "<code
+     title="">?hello=1&world=2</code>":</p>
+
+     <pre class="bad"><a href="?hello=1&world=2">Demo</a></pre>
+
+     <p>In the following fragment, however, the attribute's value is
+     actually "<code title="">?original=1©=2</code>",
+     <em>not</em> the intended "<code
+     title="">?original=1&copy=2</code>":</p>
+
+     <pre class="bad"><a href="?original=1&copy=2">Compare</a></pre>
+
+     <p>To avoid this problem, all named character references are
+     required to end with a semicolon, and any ampersands followed by
+     letters are required to be escaped.</p>
+
+     <p>Thus, the correct way to express the above cases is as
+     follows:</p>
+
+     <pre><a href="?hello=1&amp;world=2">Demo</a></pre>
+     <pre><a href="?original=1&amp;copy=2">Compare</a></pre>
+
+    </div>
+
+   </dd>
+
+
+   <dt>Errors that flag known interoperability problems in legacy user agents</dt>
+
+   <dd>
+
+    <p>Certain syntax constructs are known to cause especially subtle
+    or serious problems in legacy user agents, and are therefore
+    marked as non-conforming to help authors avoid them.</p>
+
+    <div class="example">
+
+     <p>For example, this is why the U+0060 GRAVE ACCENT character (`)
+     is not allowed in unquoted attributes. In certain legacy user
+     agents, <!-- namely IE --> it is sometimes treated as a quote
+     character.</p>
+
+    </div>
+
+    <div class="example">
+
+     <p>Another example of this is the DOCTYPE, which is required to
+     trigger <span>no-quirks mode</span>, because the behavior of
+     legacy user agents in <span>quirks mode</span> is often largely
+     undocumented.</p>
+
+    </div>
+
+   </dd>
+
+
+   <dt>Errors that protect authors from security attacks</dt>
+
+   <dd>
+
+    <p>Certain restrictions exist purely to avoid known security
+    problems.</p>
+
+    <div class="example">
+
+     <p>For example, the restriction on using UTF-7 exists purely to
+     avoid authors falling prey to a known cross-site-scripting attack
+     using UTF-7.</p>
+
+    </div>
+
+   </dd>
+
+
+   <dt>Cases where the author's intent is unclear</dt>
+
+   <dd>
+
+    <p>Some errors merely flag cases where the author's intent is most
+    unclear. Correcting these errors early makes later maintenance easier.</p>
+
+    <div class="example">
+
+     <p>For example, it is unclear whether the author intended the
+     following to be an <code>h1</code> heading or an <code>h2</code>
+     heading:</p>
+
+     <pre class="bad"><h1>Contact details</h2></pre>
+
+    </div>
+
+   </dd>
+
+
+   <dt>Cases that are likely to be typos</dt>
+
+   <dd>
+
+    <p>When a user makes a simple typo, it is helpful if the error can
+    be caught early, as this can save the author a lot of debugging
+    time. This specification therefore usually considers it an error
+    to use element names, attribute names, and so forth, that do not
+    match the names defined in this specification.</p>
+
+    <div class="example">
+
+     <p>For example, if the author typed <code><capton></code>
+     instead of <code><caption></code>, this would be flagged as an
+     error and the author could correct the typo immediately.</p>
+
+    </div>
+
+   </dd>
+
+
+   <dt>Errors that allow for new syntax in future</dt>
+
+   <dd>
+
+    <p>In order to allow us to extend the language syntax in the
+    future, certain otherwise harmless features are disallowed.</p>
+
+    <div class="example">
+
+     <p>For example, "attributes" in end tags are ignored currently,
+     but they are invalid, in case a future change to the language
+     makes use of that syntax feature without conflicting with
+     already-deployed (and valid!) content.</p>
+
+    </div>
+
+   </dd>
+
+
+  </dl>
+
+  <p>Some authors find it helpful to be in the practice of always
+  quoting all attributes and always including all optional tags,
+  preferring the consistency derived from such custom over the minor
+  benefits of terseness afforded by making use of the flexibility of
+  the HTML syntax. To aid such authors, conformance checkers can
+  provide modes of operation wherein such conventions are
+  enforced.</p>
+
+
+  <h4>Restrictions on the content model and on attribute values</h4>
+
+  <p><i>This section is non-normative.</i></p>
+
+  <p>Beyond the syntax of the language, this specification also places
+  restrictions on how elements and attributes can be specified. These
+  restrictions are present for similar reasons:</p>
+
+  <dl>
+
+
+   <dt>Errors that flag content with dubious semantics</dt>
+
+   <dd>
+
+    <p>To avoid misuse of elements with defined meanings, content
+    models are defined that restrict how elements can be nested when
+    such nestings would be of dubious value.</p>
+
+    <p class="example">For example, this specification disallows
+    nesting a <code>section</code> element inside a <code>kbd</code>
+    element, since it is highly unlikely for an author to indicate
+    that an entire section should be keyed in.</p>
+
+   </dd>
+
+
+   <dt>Errors that indicate a conflict in expressed semantics</dt>
+
+   <dd>
+
+    <p>Similarly, to draw the author's attention to mistakes in the
+    use of elements, clear contradictions in the semantics expressed
+    are also considered conformance errors.</p>
+
+    <div class="example">
+
+     <p>In the fragments below, for example, the semantics are
+     nonsensical: a row cannot simultaneously be a cell, nor can a
+     radio button be a progress bar.</p>
+
+     <pre class="bad"><tr role="cell"></pre>
+     <pre class="bad"><input type=radio role=progressbar></pre>
+
+    </div>
+
+   </dd>
+
+
+   <dt>Errors that encourage a correct understanding of the spec</dt>
+
+   <dd>
+
+    <p>Sometimes, something is disallowed because allowing it would
+    likely cause author confusion.</p>
+
+    <p class="example">For example, setting the <code
+    title="attr-fe-disabled">disabled</code> attribute to the value
+    "<code title="">false</code>" is disallowed, because despite the
+    appearance of meaning that the element is enabled, it in fact
+    means that the element is <em>disabled</em> (what matters for
+    implementations it the presence of the attribute, not its
+    value).</p>
+
+   </dd>
+
+
+   <dt>Errors that are intended merely to simplify the language</dt>
+
+   <dd>
+
+    <p>Some conformance errors simplify the language that authors need
+    to learn.</p>
+
+    <p class="example">For example, the <code>area</code> element's
+    <code title="attr-area-shape">shape</code> attribute, despite
+    accepting both <code
+    title="attr-area-shape-keyword-circ">circ</code> and <code
+    title="attr-area-shape-keyword-circle">circle</code> values in
+    practice as synonyms, disallows the use of the <code
+    title="attr-area-shape-keyword-circ">circ</code> value, so as to
+    simplify tutorials and other learning aids. There would be no
+    benefit to allowing both, but it would cause extra confusion when
+    teaching the language.</p>
+
+   </dd>
+
+
+   <dt>Errors that would likely result in scripts failing in hard-to-debug ways</dt>
+
+   <dd>
+
+    <p>Some errors are intended to help prevent script problems that
+    would be hard to debug.</p>
+
+    <p class="example">This is why, for instance, it is non-conforming
+    to have two <code title="attr-id">id</code> attributes with the
+    same value. Duplicate IDs lead to the wrong element being
+    selected, with sometimes disastrous effects whose cause is hard to
+    determine.</p>
+
+   </dd>
+
+
+   <dt>Errors that are intended to save the author time</dt>
+
+   <dd>
+
+    <p>Some constructs are disallowed because historically they have
+    been the cause of a lot of wasted authoring time.</p>
+
+    <p class="example">For example, a <code>script</code> element's
+    <code title="attr-script-src">src</code> attribute causes the
+    element's contents to be ignored. However, this isn't obvious,
+    especially if the element's contents appear to be executable
+    script — which can lead to authors spending a lot of time
+    trying to debug the inlien script without realising that it is not
+    executing. To reduce this problem, this specifications makes it
+    non-conforming to have executable script in a <code>script</code>
+    element when the <code title="attr-script-src">src</code>
+    attribute is present. This means that authors who are validating
+    their documents are less likely to waste time with this kind of
+    mistake.</p>
+
+   </dd>
+
+
+   <dt>Errors that are intended to help authors of polyglot documents</dt>
+
+   <dd>
+
+    <p>Some authors like to write files that can be interpreted as
+    both XML and HTML with similar results. These are known as
+    polyglot documents. Though this practice is discouraged in general
+    due to the myriad of subtle complications involved (especially
+    when involving scripting, styling, or any kind of automated
+    serialization), this specification has a few restrictions intended
+    to at least somewhat mitigate the difficulties.</p>
+
+    <p class="example">For example, there are somewhat complicated
+    rules surrounding the <code title="attr-lang">lang</code> and
+    <code title="attr-xml-lang">xml:lang</code> attributes intended
+    to keep the two synchronized.</p>
+
+    <p class="example">Another example would be the restrictions on
+    the values of <code title="">xmlns</code> attributes in the HTML
+    serialization, which are intended to ensure that elements in
+    conforming polyglot documents end up in the same namespaces
+    whether processed as HTML or XML.</p>
+
+   </dd>
+
+
+   <dt>Errors that reserve space for future expansion</dt>
+
+   <dd>
+
+    <p>As with the restrictions on the syntax intended to allow for
+    new syntax in future revisions of the language, some restrictions
+    on the content models of elements and values of attributes are
+    intended to allow for future expansion of the HTML vocabulary.</p>
+
+    <p class="example">For example, limiting the values of the <code
+    title="attr-hyperlink-target">target</code> attribute that start
+    with an U+005F LOW LINE character (_) to only specific predefined
+    values allows new predefined values to be introduced at a future
+    time without conflicting with author-defined values.</p>
+ 
+   </dd>
+
+
+   <dt>Errors that indicate a mis-use of other specifications</dt>
+
+   <dd>
+
+    <p>Certain restrictions are intended to support the restrictions
+    made by other specifications.</p>
+
+    <p class="example">For example, requiring that attributes that
+    take media queries use only <em>valid</em> media queries
+    reinforces the importance of following the conformance rules of
+    that specification.</p>
+
+   </dd>
+
+  </dl>
+
+
+
   <h3>Recommended reading</h3>
 
   <p><i>This section is non-normative.</i></p>




More information about the Commit-Watchers mailing list