[whatwg] Tag Soup: Blocks-in-inlines

Lachlan Hunt lachlan.hunt at lachy.id.au
Wed Jan 25 18:46:09 PST 2006


Ian Hickson wrote:
> On Wed, 25 Jan 2006, Lachlan Hunt wrote:
>> 1.
>> <em><p>X</em>Y</p>
>>
>> BODY
>>   + P
>>     + EM
>>       + #text: X
>>     + #text: Y
> 
> This is what the spec currently says. I got pretty strong feedback from 
> browser devs that it wasn't acceptable. There are performance concerns, 
> but the biggest problem with it is on markup like this:
> 
>    <a href="">
>     <h3>...</h3>
>     <h3>...</h3>
>    </a>

Ah nuts.  Now that you mention it, though, I've even worked on pages 
(not originally created by me) with almost this exact scenario that 
would break if it were fixed, and in fact I couldn't fix it at the time 
for this very reason.

> Safari at one point did it in this way and they had to change to their 
> current method because of it.

Oh, yes.  I remember reading about that somewhere (probably Hyatt's blog).

>> I believe all of these trees meet the requirements of coherence with 
>> regards to the DOM, transparency with regards to CSS and, most 
>> certainly, predictability.  It also seems perfectly backwards compatible 
>> with the rendering achieved in all browsers, but with a much saner DOM 
>> under the hood.
> 
> I agree. I wish we could do it this way. I even specced it out. :-)

Oh well, then I guess the adoption agency method is the way to go, as 
long as we make sure (to the best of our abilities) that browsers can't 
crash because of it (like you mentioned Safari does).

Also, it may need some more improvement, I found an incredibly insane 
condition that fails in Safari and another that fails a little in Mozilla.

<!DOCTYPE html>
<em><p><span><h1>X</em>Y</span>Z</h1></p>

Mozilla:
BODY
   + EM
   + P
     + SPAN
       + H1
         + EM
           + #text: X
         + #text: YZ

That look reasonably like what the author would want with that rubbish, 
except that the Z is within the span, but it's not in the markup.  If 
you swap <span> with <strong>, the result is even more perplexing, but 
the Z is not put within the STRONG element)

Safari:
BODY
   + EM
     + P
       + SPAN
         + H1
            + #text: X
            + #text: Y
            + #text: Z

In this case, it's all emphasised, instead of just the X like it is in 
Mozilla.  If you swap <span> with <strong>, the result is almost the 
same, except there is an additional empty STRONG element added as a 
child of the EM, after the P for no apparent reason.)

-- 
Lachlan Hunt
http://lachy.id.au/




More information about the whatwg mailing list