[html5] r5922 - [e] (0) Tweak the conformance section a bit so we can have a 'conformance classe [...]
whatwg at whatwg.org
whatwg at whatwg.org
Tue Mar 1 14:57:16 PST 2011
Author: ianh
Date: 2011-03-01 14:57:14 -0800 (Tue, 01 Mar 2011)
New Revision: 5922
Modified:
complete.html
index
source
Log:
[e] (0) Tweak the conformance section a bit so we can have a 'conformance classes' subsection.
Modified: complete.html
===================================================================
--- complete.html 2011-03-01 00:18:41 UTC (rev 5921)
+++ complete.html 2011-03-01 22:57:14 UTC (rev 5922)
@@ -337,8 +337,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>
@@ -2941,12 +2942,30 @@
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>
- <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>
+ <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>
@@ -2965,10 +2984,13 @@
would imply that documents are not allowed to contain elements named
<code title="">foobar</code>.</p>
- <div class=impl>
+ <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>
@@ -3182,7 +3204,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
@@ -3194,52 +3240,12 @@
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>
-
- <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>
-
- <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.</p>
-
-
<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>
@@ -3442,7 +3448,7 @@
- <h4 id=extensibility><span class=secno>2.2.2 </span>Extensibility</h4>
+ <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:</p>
Modified: index
===================================================================
--- index 2011-03-01 00:18:41 UTC (rev 5921)
+++ index 2011-03-01 22:57:14 UTC (rev 5922)
@@ -345,8 +345,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>
@@ -2921,12 +2922,30 @@
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>
- <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>
+ <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>
@@ -2945,10 +2964,13 @@
would imply that documents are not allowed to contain elements named
<code title="">foobar</code>.</p>
- <div class=impl>
+ <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>
@@ -3162,7 +3184,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
@@ -3174,52 +3220,12 @@
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>
-
- <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>
-
- <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.</p>
-
-
<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>
@@ -3422,7 +3428,7 @@
- <h4 id=extensibility><span class=secno>2.2.2 </span>Extensibility</h4>
+ <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:</p>
Modified: source
===================================================================
--- source 2011-03-01 00:18:41 UTC (rev 5921)
+++ source 2011-03-01 22:57:14 UTC (rev 5922)
@@ -1829,12 +1829,30 @@
not appear in all uppercase letters in this specification. <a
href="#refsRFC2119">[RFC2119]</a></p>
- <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>
+ <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>
+
+
+
+<!--END microdata-->
+
+ <div class="impl">
+
+ <h4>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
@@ -1854,10 +1872,13 @@
would imply that documents are not allowed to contain elements named
<code title="">foobar</code>.</p>
- <div class="impl">
+ <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>
-<!--END microdata-->
-
<p>User agents fall into several (overlapping) categories with
different conformance requirements.</p>
@@ -2089,8 +2110,31 @@
</dl>
-<!--START microdata-->
+ <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 <span>the XHTML syntax</span>), and one using a <a
+ href="#writing">custom format</a> inspired by SGML (referred to as
+ <span>the HTML syntax</span>). 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,
@@ -2103,50 +2147,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>
-<!--END microdata-->
- <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>For compatibility with existing content and prior specifications,
- this specification describes two authoring formats: one based on XML
- (referred to as <span>the XHTML syntax</span>), and one using a <a
- href="#writing">custom format</a> inspired by SGML (referred to as
- <span>the HTML syntax</span>). <span class="impl">Implementations
- must support at least one of these two formats, although supporting
- both is encouraged.</span></p>
-
- <p id="entity-references" class="impl">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>
-
-
<div class="impl">
<h4>Dependencies</h4>
More information about the Commit-Watchers
mailing list