hixie: Tweak the conformance section a bit so we can have a 'conformance classes' subsection. (whatwg r5922)

hixie: Tweak the conformance section a bit so we can have a 'conformance
classes' subsection. (whatwg r5922)

http://dev.w3.org/cvsweb/html5/spec/Overview.html?r1=1.4762&r2=1.4763&f=h
http://html5.org/tools/web-apps-tracker?from=5921&to=5922

===================================================================
RCS file: /sources/public/html5/spec/Overview.html,v
retrieving revision 1.4762
retrieving revision 1.4763
diff -u -d -r1.4762 -r1.4763
--- Overview.html 1 Mar 2011 00:18:50 -0000 1.4762
+++ Overview.html 1 Mar 2011 22:57:26 -0000 1.4763
@@ -532,8 +532,9 @@
      <li><a href="#character-encodings"><span class="secno">2.1.6 </span>Character encodings</a></ol></li>
    <li><a href="#conformance-requirements"><span class="secno">2.2 </span>Conformance requirements</a>
     <ol>
-     <li><a href="#dependencies"><span class="secno">2.2.1 </span>Dependencies</a></li>
-     <li><a href="#extensibility"><span class="secno">2.2.2 </span>Extensibility</a></ol></li>
+     <li><a href="#conformance-classes"><span class="secno">2.2.1 </span>Conformance classes</a></li>
+     <li><a href="#dependencies"><span class="secno">2.2.2 </span>Dependencies</a></li>
+     <li><a href="#extensibility"><span class="secno">2.2.3 </span>Extensibility</a></ol></li>
    <li><a href="#case-sensitivity-and-string-comparison"><span class="secno">2.3 </span>Case-sensitivity and string comparison</a></li>
    <li><a href="#utf-8"><span class="secno">2.4 </span>UTF-8</a></li>
    <li><a href="#common-microsyntaxes"><span class="secno">2.5 </span>Common microsyntaxes</a>
@@ -2522,25 +2523,48 @@
   NOT",--> "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
   "OPTIONAL" in the normative parts of this document are to be
   interpreted as described in RFC2119. For readability, these words do
-  not appear in all uppercase letters in this specification. <a href="#refsRFC2119">[RFC2119]</a><p class="impl">Requirements phrased in the imperative as part of
-  algorithms (such as "strip any leading space characters" or "return
-  false and abort these steps") are to be interpreted with the meaning
-  of the key word ("must", "should", "may", etc) used in introducing
-  the algorithm.<p>This specification describes the conformance criteria for <span class="impl">user agents (relevant to implementors) and</span>
+  not appear in all uppercase letters in this specification. <a href="#refsRFC2119">[RFC2119]</a><div class="impl">
+
+  <p>Requirements phrased in the imperative as part of algorithms
+  (such as "strip any leading space characters" or "return false and
+  abort these steps") are to be interpreted with the meaning of the
+  key word ("must", "should", "may", etc) used in introducing the
+  algorithm.</p>
+
+  <p>Conformance requirements phrased as algorithms or specific steps
+  may be implemented in any manner, so long as the end result is
+  equivalent. (In particular, the algorithms defined in this
+  specification are intended to be easy to follow, and not intended to
+  be performant.)</p>
+
+  </div><div class="impl">
+
+  <h4 id="conformance-classes"><span class="secno">2.2.1 </span>Conformance classes</h4>
+
+  <p>This specification describes the conformance criteria for <span class="impl">user agents (relevant to implementors) and</span>
   documents<span class="impl"> (relevant to authors and authoring tool
-  implementors)</span>.<p><dfn id="conforming-documents">Conforming documents</dfn> are those that comply with all
+  implementors)</span>.</p>
+
+  <p><dfn id="conforming-documents">Conforming documents</dfn> are those that comply with all
   the conformance criteria for documents. For readability, some of
   these conformance requirements are phrased as conformance
   requirements on authors; such requirements are implicitly
   requirements on documents: by definition, all documents are assumed
   to have had an author. (In some cases, that author may itself be a
   user agent &mdash; such user agents are subject to additional rules,
-  as explained below.)<p class="example">For example, if a requirement states that
+  as explained below.)</p>
+
+  <p class="example">For example, if a requirement states that
   "authors must not use the <code title="">foobar</code> element", it
   would imply that documents are not allowed to contain elements named
-  <code title="">foobar</code>.<div class="impl">
-
+  <code title="">foobar</code>.</p>
 
+  <p class="note impl">There is no implied relationship between
+  document conformance requirements and implementation conformance
+  requirements. User agents are not free to handle non-conformant
+  documents as they please; the processing model described in this
+  specification applies to implementations regardless of the
+  conformity of the input documents.</p>
 
   <p>User agents fall into several (overlapping) categories with
   different conformance requirements.</p>
@@ -2755,7 +2779,31 @@
 
    </dd>
 
-  </dl><p>Some conformance requirements are phrased as requirements on
+  </dl><p id="hardwareLimitations">User agents may impose
+  implementation-specific limits on otherwise unconstrained inputs,
+  e.g. to prevent denial of service attacks, to guard against running
+  out of memory, or to work around platform-specific limitations.</p>
+
+  <p>For compatibility with existing content and prior specifications,
+  this specification describes two authoring formats: one based on XML
+  (referred to as <a href="#the-xhtml-syntax">the XHTML syntax</a>), and one using a <a href="#writing">custom format</a> inspired by SGML (referred to as
+  <a href="#syntax">the HTML syntax</a>). Implementations must support at least
+  one of these two formats, although supporting both is
+  encouraged.</p>
+
+  <p id="entity-references">The language in this specification assumes
+  that the user agent expands all entity references, and therefore
+  does not include entity reference nodes in the DOM. If user agents
+  do include entity reference nodes in the DOM, then user agents must
+  handle them as if they were fully expanded when implementing this
+  specification. For example, if a requirement talks about an
+  element's child text nodes, then any text nodes that are children of
+  an entity reference that is a child of that element would be used as
+  well. Entity references to unknown entities must be treated as if
+  they contained just an empty text node for the purposes of the
+  algorithms defined in this specification.</p>
+
+  <p>Some conformance requirements are phrased as requirements on
   elements, attributes, methods or objects. Such requirements fall
   into two categories: those describing content model restrictions,
   and those describing implementation behavior. Those in the former
@@ -2767,41 +2815,9 @@
   specification does not distinguish between conformance criteria on
   authors and conformance criteria on documents.)</p>
 
-  <p>Conformance requirements phrased as algorithms or specific steps
-  may be implemented in any manner, so long as the end result is
-  equivalent. (In particular, the algorithms defined in this
-  specification are intended to be easy to follow, and not intended to
-  be performant.)</p>
-
-  <p id="hardwareLimitations">User agents may impose
-  implementation-specific limits on otherwise unconstrained inputs,
-  e.g. to prevent denial of service attacks, to guard against running
-  out of memory, or to work around platform-specific limitations.</p>
-
-  </div><p class="note impl">There is no implied relationship between
-  document conformance requirements and implementation conformance
-  requirements. User agents are not free to handle non-conformant
-  documents as they please; the processing model described in this
-  specification applies to implementations regardless of the
-  conformity of the input documents.<p>For compatibility with existing content and prior specifications,
-  this specification describes two authoring formats: one based on XML
-  (referred to as <a href="#the-xhtml-syntax">the XHTML syntax</a>), and one using a <a href="#writing">custom format</a> inspired by SGML (referred to as
-  <a href="#syntax">the HTML syntax</a>). <span class="impl">Implementations
-  must support at least one of these two formats, although supporting
-  both is encouraged.</span><p class="impl" id="entity-references">The language in this
-  specification assumes that the user agent expands all entity
-  references, and therefore does not include entity reference nodes in
-  the DOM. If user agents do include entity reference nodes in the
-  DOM, then user agents must handle them as if they were fully
-  expanded when implementing this specification. For example, if a
-  requirement talks about an element's child text nodes, then any text
-  nodes that are children of an entity reference that is a child of
-  that element would be used as well. Entity references to unknown
-  entities must be treated as if they contained just an empty text
-  node for the purposes of the algorithms defined in this
-  specification.<div class="impl">
+  </div><div class="impl">
 
-  <h4 id="dependencies"><span class="secno">2.2.1 </span>Dependencies</h4>
+  <h4 id="dependencies"><span class="secno">2.2.2 </span>Dependencies</h4>
 
   <p>This specification relies on several other underlying
   specifications.</p>
@@ -3000,7 +3016,7 @@
   requirements on character encodings, image formats, audio formats,
   and video formats in the respective sections.</p>
 
-  </div><h4 id="extensibility"><span class="secno">2.2.2 </span>Extensibility</h4><p>HTML has a wide number of extensibility mechanisms that can be
+  </div><h4 id="extensibility"><span class="secno">2.2.3 </span>Extensibility</h4><p>HTML has a wide number of extensibility mechanisms that can be
   used for adding semantics in a safe manner:<ul><li>Authors can use the <code title="attr-class"><a href="#classes">class</a></code>
    attribute to extend elements, effectively creating their own
    elements, while using the most applicable existing "real" HTML

Received on Tuesday, 1 March 2011 22:58:44 UTC