- From: Ian Hickson <ian@hixie.ch>
- Date: Thu, 6 Dec 2007 06:22:29 +0000 (UTC)
- To: Sam Ruby <rubys@us.ibm.com>
- Cc: public-html@w3.org
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