Re: DogFood (and inline/block constraints)

On Thu, 6 Dec 2007, Sam Ruby wrote:
> 
> If the answer to the question of "why does the html5 conformance checker 
> produce this message?" is "because the spec says so"; and the answer to 
> "why does the spec say so" is "because previous specs said so"

If you are asking why the spec doesn't allow elements to have a mix of 
inline-level and block-level child elements, the reasons the spec doesn't 
allow it include (off the top of my head):

 * Mixing inline and block content makes it hard for non-visual UAs to 
   determine where to pause (the "paragraph breaks" for lack of a better 
   term)

 * Mixing inline and block content makes it very hard for editors to
   properly allow editing of content.

 * Mixing inline and block is semantically ambiguous (in the same way 
   that having a <p> element directly inside an <ol> is ambiguous), which  
   makes it hard to analyse, e.g. with scripts.

 * The use cases for mixing inlines and blocks aren't very clear, and can 
   always, to my knowledge, be better addressed without mixing inlines and 
   blocks (e.g. by using explicit <p>s).

Note that HTML4 also disallowed mixed inlines-and-blocks, except that 
possibly due to limitations of DTDs (and the HTML4 WG's apparent obsession 
with only having requirements that can be expressed in DTDs), it left some 
things vague (like allowing <div> to work around the rule despite saying 
that <div> didn't change semantics).

BTW, in recognition that these restrictions would otherwise prevent 
practices that are quite reasonable, the HTML5 spec relaxes the 
requirement as follows:

 * A number of elements are considered inline-level where possible (e.g. 
   <ol>, <ul>) -- though note that this is controversial, since it (a) 
   can't be used in text/html much and (b) seems to be difficult for 
   editors, defeating part of the point of the restriction (though it's 
   not as difficult as arbitrary mixed inlines and blocks).

 * <input type=hidden> is allowed even when other types wouldn't be -- 
   this is probably going to be extended to cover tables too, at some 
   point.

 * <div> allows inline content (though not mixed content) to allow people 
   to make custom widgets and work around ommissions in the language
   (though I'd like to tighten this up so it's harder to abuse).

However, this is far from a resolved issue. What would be especially 
useful is a study of use cases -- occurances where people mix inlines and 
blocks, and why unmixed alternatives don't really address the needs of the 
author. (Your blog would be a great start to look for such cases.)

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Thursday, 6 December 2007 06:22:53 UTC