[html5] r4966 - [e] (0) More information on the reasons for authoring conformance criteria. I ca [...]

whatwg at whatwg.org whatwg at whatwg.org
Sun Apr 4 01:56:48 PDT 2010


Author: ianh
Date: 2010-04-04 01:56:47 -0700 (Sun, 04 Apr 2010)
New Revision: 4966

Modified:
   complete.html
   index
   source
Log:
[e] (0) More information on the reasons for authoring conformance criteria. I can't wait to see other W3C and IETF specs, like SVG, Atom, or RDFa, include introduction sections explaining why _they_ all have authoring conformance criteria.
Fixing http://www.w3.org/Bugs/Public/show_bug.cgi?id=9358

Modified: complete.html
===================================================================
--- complete.html	2010-04-04 07:40:07 UTC (rev 4965)
+++ complete.html	2010-04-04 08:56:47 UTC (rev 4966)
@@ -2236,6 +2236,7 @@
   enforced.</p>
 
 
+
   <h4 id=restrictions-on-content-models-and-on-attribute-values><span class=secno>1.10.3 </span>Restrictions on content models and on attribute values</h4>
 
   <p><i>This section is non-normative.</i></p>
@@ -2279,9 +2280,45 @@
 
     </div>
 
+    <p class=example>Another example is the restrictions on the
+    content models of the <code><a href=#the-ul-element>ul</a></code> element, which only allows
+    <code><a href=#the-li-element>li</a></code> element children. Lists by definition consist just
+    of zero or more list items, so if a <code><a href=#the-ul-element>ul</a></code> element
+    contains something other than an <code><a href=#the-li-element>li</a></code> element, it's not
+    clear what was meant.</p>
+
    </dd>
 
 
+   <dt>Errors that catch cases where the default styles are likely to lead to confusion</dt>
+
+   <dd>
+
+    <p>Certain elements have default styles or behaviors that make
+    certain combinations likely to lead to confusion. Where these have
+    equivalent alternatives without this problem, the confusing
+    combinations are disallowed.</p>
+
+    <p class=example>For example, <code><a href=#the-div-element>div</a></code> elements are
+    rendered as block boxes, and <code><a href=#the-span-element>span</a></code> elements as inline
+    boxes. Putting a block box in an inline box is unnecessarily
+    confusing; since either nesting just <code><a href=#the-div-element>div</a></code> elements, or
+    nesting just <code><a href=#the-span-element>span</a></code> elements, or nesting
+    <code><a href=#the-span-element>span</a></code> elements inside <code><a href=#the-div-element>div</a></code> elements all
+    serve the same purpose as nesting a <code><a href=#the-div-element>div</a></code> element in a
+    <code><a href=#the-span-element>span</a></code> element, but only the latter involves a block
+    box in an inline box, the latter combination is disallowed.</p>
+
+    <p class=example>Another example would be the way
+    <a href=#interactive-content>interactive content</a> cannot be nested. For example, a
+    <code><a href=#the-button-element>button</a></code> element cannot contain a <code><a href=#the-textarea-element>textarea</a></code>
+    element. This is because the default behavior of such nesting
+    interactive elements would be highly confusing to users. Instead
+    of nesting these elements, they can be placed side by side.</p>
+
+   </dd>
+
+
    <dt>Errors that encourage a correct understanding of the spec</dt>
 
    <dd>
@@ -2317,6 +2354,34 @@
    </dd>
 
 
+   <dt>Errors that avoid peculiarities of the parser</dt>
+
+   <dd>
+
+    <p>Certain elements are parsed in someone eccentric ways
+    (typically for historical reasons), and their content model
+    restrictions are intended to avoid exposing the author to these
+    issues.</p>
+
+    <div class=example>
+
+     <p>For example, a <code><a href=#the-form-element>form</a></code> element isn't allowed inside
+     <a href=#phrasing-content>phrasing content</a>, because when parsed as HTML, a
+     <code><a href=#the-form-element>form</a></code> element's start tag will imply a <code><a href=#the-p-element>p</a></code>
+     element's end tag. Thus, the following markup results in two
+     <a href=#paragraph title=paragraph>paragraphs</a>, not one:</p>
+
+     <pre><p>Welcome. <form><label>Name:</label> <input></form></pre>
+
+     <p>It is parsed exactly like the following:</p>
+
+     <pre><p>Welcome. </p><form><label>Name:</label> <input></form></pre>
+
+    </div>
+
+   </dd>
+
+
    <dt>Errors that would likely result in scripts failing in hard-to-debug ways</dt>
 
    <dd>

Modified: index
===================================================================
--- index	2010-04-04 07:40:07 UTC (rev 4965)
+++ index	2010-04-04 08:56:47 UTC (rev 4966)
@@ -2134,6 +2134,7 @@
   enforced.</p>
 
 
+
   <h4 id=restrictions-on-content-models-and-on-attribute-values><span class=secno>1.10.3 </span>Restrictions on content models and on attribute values</h4>
 
   <p><i>This section is non-normative.</i></p>
@@ -2177,9 +2178,45 @@
 
     </div>
 
+    <p class=example>Another example is the restrictions on the
+    content models of the <code><a href=#the-ul-element>ul</a></code> element, which only allows
+    <code><a href=#the-li-element>li</a></code> element children. Lists by definition consist just
+    of zero or more list items, so if a <code><a href=#the-ul-element>ul</a></code> element
+    contains something other than an <code><a href=#the-li-element>li</a></code> element, it's not
+    clear what was meant.</p>
+
    </dd>
 
 
+   <dt>Errors that catch cases where the default styles are likely to lead to confusion</dt>
+
+   <dd>
+
+    <p>Certain elements have default styles or behaviors that make
+    certain combinations likely to lead to confusion. Where these have
+    equivalent alternatives without this problem, the confusing
+    combinations are disallowed.</p>
+
+    <p class=example>For example, <code><a href=#the-div-element>div</a></code> elements are
+    rendered as block boxes, and <code><a href=#the-span-element>span</a></code> elements as inline
+    boxes. Putting a block box in an inline box is unnecessarily
+    confusing; since either nesting just <code><a href=#the-div-element>div</a></code> elements, or
+    nesting just <code><a href=#the-span-element>span</a></code> elements, or nesting
+    <code><a href=#the-span-element>span</a></code> elements inside <code><a href=#the-div-element>div</a></code> elements all
+    serve the same purpose as nesting a <code><a href=#the-div-element>div</a></code> element in a
+    <code><a href=#the-span-element>span</a></code> element, but only the latter involves a block
+    box in an inline box, the latter combination is disallowed.</p>
+
+    <p class=example>Another example would be the way
+    <a href=#interactive-content>interactive content</a> cannot be nested. For example, a
+    <code><a href=#the-button-element>button</a></code> element cannot contain a <code><a href=#the-textarea-element>textarea</a></code>
+    element. This is because the default behavior of such nesting
+    interactive elements would be highly confusing to users. Instead
+    of nesting these elements, they can be placed side by side.</p>
+
+   </dd>
+
+
    <dt>Errors that encourage a correct understanding of the spec</dt>
 
    <dd>
@@ -2215,6 +2252,34 @@
    </dd>
 
 
+   <dt>Errors that avoid peculiarities of the parser</dt>
+
+   <dd>
+
+    <p>Certain elements are parsed in someone eccentric ways
+    (typically for historical reasons), and their content model
+    restrictions are intended to avoid exposing the author to these
+    issues.</p>
+
+    <div class=example>
+
+     <p>For example, a <code><a href=#the-form-element>form</a></code> element isn't allowed inside
+     <a href=#phrasing-content>phrasing content</a>, because when parsed as HTML, a
+     <code><a href=#the-form-element>form</a></code> element's start tag will imply a <code><a href=#the-p-element>p</a></code>
+     element's end tag. Thus, the following markup results in two
+     <a href=#paragraph title=paragraph>paragraphs</a>, not one:</p>
+
+     <pre><p>Welcome. <form><label>Name:</label> <input></form></pre>
+
+     <p>It is parsed exactly like the following:</p>
+
+     <pre><p>Welcome. </p><form><label>Name:</label> <input></form></pre>
+
+    </div>
+
+   </dd>
+
+
    <dt>Errors that would likely result in scripts failing in hard-to-debug ways</dt>
 
    <dd>

Modified: source
===================================================================
--- source	2010-04-04 07:40:07 UTC (rev 4965)
+++ source	2010-04-04 08:56:47 UTC (rev 4966)
@@ -1069,6 +1069,7 @@
   enforced.</p>
 
 
+
   <h4>Restrictions on content models and on attribute values</h4>
 
   <p><i>This section is non-normative.</i></p>
@@ -1115,9 +1116,45 @@
 
     </div>
 
+    <p class="example">Another example is the restrictions on the
+    content models of the <code>ul</code> element, which only allows
+    <code>li</code> element children. Lists by definition consist just
+    of zero or more list items, so if a <code>ul</code> element
+    contains something other than an <code>li</code> element, it's not
+    clear what was meant.</p>
+
    </dd>
 
 
+   <dt>Errors that catch cases where the default styles are likely to lead to confusion</dt>
+
+   <dd>
+
+    <p>Certain elements have default styles or behaviors that make
+    certain combinations likely to lead to confusion. Where these have
+    equivalent alternatives without this problem, the confusing
+    combinations are disallowed.</p>
+
+    <p class="example">For example, <code>div</code> elements are
+    rendered as block boxes, and <code>span</code> elements as inline
+    boxes. Putting a block box in an inline box is unnecessarily
+    confusing; since either nesting just <code>div</code> elements, or
+    nesting just <code>span</code> elements, or nesting
+    <code>span</code> elements inside <code>div</code> elements all
+    serve the same purpose as nesting a <code>div</code> element in a
+    <code>span</code> element, but only the latter involves a block
+    box in an inline box, the latter combination is disallowed.</p>
+
+    <p class="example">Another example would be the way
+    <span>interactive content</span> cannot be nested. For example, a
+    <code>button</code> element cannot contain a <code>textarea</code>
+    element. This is because the default behavior of such nesting
+    interactive elements would be highly confusing to users. Instead
+    of nesting these elements, they can be placed side by side.</p>
+
+   </dd>
+
+
    <dt>Errors that encourage a correct understanding of the spec</dt>
 
    <dd>
@@ -1157,6 +1194,34 @@
    </dd>
 
 
+   <dt>Errors that avoid peculiarities of the parser</dt>
+
+   <dd>
+
+    <p>Certain elements are parsed in someone eccentric ways
+    (typically for historical reasons), and their content model
+    restrictions are intended to avoid exposing the author to these
+    issues.</p>
+
+    <div class="example">
+
+     <p>For example, a <code>form</code> element isn't allowed inside
+     <span>phrasing content</span>, because when parsed as HTML, a
+     <code>form</code> element's start tag will imply a <code>p</code>
+     element's end tag. Thus, the following markup results in two
+     <span title="paragraph">paragraphs</span>, not one:</p>
+
+     <pre><p>Welcome. <form><label>Name:</label> <input></form></pre>
+
+     <p>It is parsed exactly like the following:</p>
+
+     <pre><p>Welcome. </p><form><label>Name:</label> <input></form></pre>
+
+    </div>
+
+   </dd>
+
+
    <dt>Errors that would likely result in scripts failing in hard-to-debug ways</dt>
 
    <dd>




More information about the Commit-Watchers mailing list