Re: restrictions on blocks inside inlines (was Re: HTML5 Authoring Conformance Study)

Maciej Stachowiak, Sun, 21 Mar 2010 13:11:35 -0700:
> On Mar 21, 2010, at 9:14 AM, L. David Baron wrote:
>> On Sunday 2010-03-21 08:22 -0400, Sam Ruby wrote:
>>> youtube.com:
>>> 
>>> What interop issues are solved by disallowing div elements inside of
>>> span elements?
>> 
>> Blocks inside inlines can, in some cases, cause larger numbers of
>> CSS boxes to be present than the author probably expects, which I
>> believe in some cases causes performance degradation.  (I've seen
>> cases in the past where such performance degradation was
>> significant, although those cases may have been fixed in our
>> implementation.)
>> 
>> In many cases, the author intends the outer element to have block
>> formatting.  In the other cases, I believe the resulting formatting
>> is non-tree-like, which confuses the mental model of the HTML
>> element structure representing a tree.
> 
> Good point. Blocks inside inlines create a very strange render tree 
> and this can have unexpected side effects. I have had to help web 
> developers at Apple with problems resulting from this a couple of 
> times. On the other hand, HTML5 allows nesting block-level elements 
> inside the <a> element. Perhaps in that case the benefits exceed the 
> costs.
> 
> (Note for Leif: neither <caption> nor the <hn> elements are inlines.)

I did not say that <hn> was inline. Don't spread that rumour. ;-)

But when you say that <caption> is not an inline, then what do you base 
that on? CSS? According to HTML4 - and thus also according to XHTML1, 
it is an inline. (And may be this the reason for why <caption> was very 
difficult to style in Firefox?) We cannot solve the problem of whether 
it logical/permitted to have <div> inside <span> by saying that <span> 
is a block. And at least it breaks my mental model of HTML that it 
should be permitted with blocks inside <caption>.

OTOH, when it comes to <hn> vs <caption>, then they many semantic 
features together. And they also have the same content models - in 
HTML4: they don't accept block level content. However, HTML4 has a 
loophole, and it is called <object>. (<map> is another loophole.) You 
can place a block inside either of those, and then drop them inside 
<caption> or <hn>. This supports my mental model of HTML, because e.g 
<object> is like some kind of inline-block object. I guess only the bad 
rumour that <object> has had has prevented people from doing this. 
HTML4 also doesn't have any requirement for @type or @data to be 
present on the OBJECT element. However ... the authoring guidelines of 
HTML5 makes this invalid ... bah! Of course such an <object> (with 
blocks inside) can also go inside an inline element. The requirement to 
use a special element whenever block level elements are needed in 
"illogical" places, calls attention to the problem, and in my view 
seems like a good way to solve the problem in a way that makes authors 
aware of the problem.

But I don't think Sam asked specifically about block inside inline. Or, 
at the very least, one could also ask why it isn't permitted to have 
block elements inside <hn>. Why?

That question is for instance related to the <hgroup> element - we 
don't need <hgroup> if we can place block elements inside <hn> 
elements. I can also not see that we need <hgroup> if we can place 
block elements inside <object> inside <hn>. As I have said before: 
<h1><object><p>abc<p>def</object></h1> is more compatible with html 
outline interpreters than <hgroup><h1>....</h1</hgroup> is.

So, to hammer down a point: The authoring requirements of HTML5 are not 
only related to authoring, but even to which kind of new elements HTML5 
should have.
-- 
leif halvard silli

Received on Monday, 22 March 2010 00:28:25 UTC