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

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

From: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
Date: Mon, 22 Mar 2010 01:27:50 +0100
To: Maciej Stachowiak <mjs@apple.com>
Cc: "L. David Baron" <dbaron@dbaron.org>, HTMLwg WG <public-html@w3.org>
Message-ID: <20100322012750819940.a2bd0f97@xn--mlform-iua.no>
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

This archive was generated by hypermail 2.4.0 : Saturday, 9 October 2021 18:45:13 UTC