[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