- From: Ian Hickson via cvs-syncmail <cvsmail@w3.org>
- Date: Sun, 04 Apr 2010 08:56:55 +0000
- To: public-html-commits@w3.org
Update of /sources/public/html5/spec
In directory hutz:/tmp/cvs-serv30200
Modified Files:
Overview.html
Log Message:
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. (whatwg r4966)
Index: Overview.html
===================================================================
RCS file: /sources/public/html5/spec/Overview.html,v
retrieving revision 1.3987
retrieving revision 1.3988
diff -u -d -r1.3987 -r1.3988
--- Overview.html 4 Apr 2010 07:43:12 -0000 1.3987
+++ Overview.html 4 Apr 2010 08:56:51 -0000 1.3988
@@ -1915,6 +1915,42 @@
</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>
@@ -1953,6 +1989,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>
Received on Sunday, 4 April 2010 08:56:57 UTC