W3C home > Mailing lists > Public > public-html-commits@w3.org > April 2010

html5/spec Overview.html,1.3987,1.3988

From: Ian Hickson via cvs-syncmail <cvsmail@w3.org>
Date: Sun, 04 Apr 2010 08:56:55 +0000
To: public-html-commits@w3.org
Message-Id: <E1NyLdX-0007rZ-Fm@lionel-hutz.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>&lt;p&gt;Welcome. &lt;form&gt;&lt;label&gt;Name:&lt;/label&gt; &lt;input&gt;&lt;/form&gt;</pre>
+
+     <p>It is parsed exactly like the following:</p>
+
+     <pre>&lt;p&gt;Welcome. &lt;/p&gt;&lt;form&gt;&lt;label&gt;Name:&lt;/label&gt; &lt;input&gt;&lt;/form&gt;</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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Sunday, 4 April 2010 08:56:58 GMT