- From: Ian Hickson <ian@hixie.ch>
- Date: Tue, 2 Jul 2013 16:33:27 +0000 (UTC)
- To: Michael Day <mikeday@yeslogic.com>
- Cc: whatwg@whatwg.org, Adam Barth <w3c@adambarth.com>
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 <svg> <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. `._.-(,_..'--(,_..'`-.;.'
Received on Tuesday, 2 July 2013 16:33:53 UTC