[whatwg] Another issue in parsing tokens in foreign content

Ian Hickson ian at hixie.ch
Tue Jul 2 09:33:27 PDT 2013

On Tue, 2 Jul 2013, Michael Day wrote:
> The new text reads:
> "If the parser was originally created for the HTML fragment parsing algorithm,
> then act as described in the "any other start tag" entry below. (fragment
> case)"
> This always just adds the HTML element in place inside the foreign content,
> even if the fragment context element *is* a HTML element!

Right, that's the intent.

This specific clause is a hack to make certain elements break out of 
foreign content, because we found some pages that do crazy stuff like:

   <p>Bla bla
   <p>Bla bla

...which, prior to SVG being added to HTML, would show two paragraphs, but 
if we didn't have this hack, it would now just end the page at the <svg> tag.

> This can't be right, as it means parsing document.body.innerHTML will 
> behave totally differently to parsing <html><body>, for no reason.

Not totally differently, only differently in the specific cases of these 
few tags that trigger this wacked behaviour in markup that's broken anyway.

We don't have any data that says that we need to support this for 
innerHTML. I think it's a win if we can drop the hack from innerHTML.

> Looking back a couple of years, this section of the spec seems to be 
> drifting in a random walk away from reality. We can study this further 
> and try suggesting some text based on what we have implemented so far.

Well, when it started it wasn't reality at all, since there was no foreign 
content support in text/html. :-)

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