- From: Ian Hickson via cvs-syncmail <cvsmail@w3.org>
- Date: Tue, 01 Mar 2011 22:57:31 +0000
- To: public-html-commits@w3.org
Update of /sources/public/html5/spec
In directory hutz:/tmp/cvs-serv22364
Modified Files:
Overview.html
Log Message:
Tweak the conformance section a bit so we can have a 'conformance classes' subsection. (whatwg r5922)
Index: Overview.html
===================================================================
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 — 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:57:34 UTC