[whatwg] Tag Soup: Blocks-in-inlines

Ian Hickson ian at hixie.ch
Wed Jan 25 17:09:41 PST 2006

On Wed, 25 Jan 2006, Lachlan Hunt wrote:
> However, there may be a 5th option available.  Consider this, using the
> following markup samples from the article.
> 1.
> <em><p>X</em>Y</p>
>   + P
>     + EM
>       + #text: X
>     + #text: Y
> The theory is that any inline elements started and not ended before a block
> element will immediately become a child of the block element, regardless of
> where the end tag for the inline element occurs.  This avoids the Heisenburg
> uncertainty principle employed by Mozilla.
> 2.
> <em><p>XY</p></em>
>   + 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="">

People expect this to be one link. Your method (and the method currently 
in the draft) would generate two links (one inside each <h3>). This breaks 
real-world sites, because it makes single links into two links for 
tabbing, hover effects, etc.

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

> 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. :-)

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

More information about the whatwg mailing list