- From: Ian Hickson <ian@hixie.ch>
- Date: Thu, 26 Jan 2006 01:09:41 +0000 (UTC)
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>
>
> 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
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>
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. `._.-(,_..'--(,_..'`-.;.'
Received on Wednesday, 25 January 2006 17:09:41 UTC