[whatwg] Tag Soup: Blocks-in-inlines

[Lachlan Hunt]

Hi,
   This is in response to Hixie's article [1].

I fully agree that the both IE's incestual approach and Opera's genetic 
inheritance problem (though a well-formed tree) are out of the question. 
  I like the Hiesenburg theory in some cases, although its lack of easy 
predictability is a big downfall.  Safari's adoption-agency method is 
reasonable, although we'd need to find a way to avoid the Hindenburg 
disaster when the child is kidnapped during birth.

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>

BODY
   + 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>

BODY
   + P
     + EM
       + #text: X
       + #text: Y

In this case, Mozilla would have had the <em> and <p> elements swapped 
(just like if this were a well formed XHTML document), but that requires 
some pre-parsing which I imagine would be a pain for incremental rendering.

3.
<em><p>X</p><p>Y</p></em>

BODY
   + P
     + EM
       + #text: X
   + P
     + EM
       + #text: Y

This is exactly the same as the last one, except there were two block 
level elements within the inline element, and as such, the inline 
element was cloned and each parent was given custody of one, which 
nicely avoids the time consuming and painful child custody hearings.

4.
<em>X<p>Y</em>Z</p>

BODY
   + EM
     + #text: X
   + P
     + EM
       + #text: Y
     + #text: Z

This is almost the same as the first example, except that there is a 
text node within the em element which is not a child of the p element. 
So, again the em element is cloned.  The first becomes a parent of X, 
the second becomes the parent of Y, the child of P and the brother of Z.

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.

[1] http://ln.hixie.ch/?start=1138169545&count=1

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