14288 2011-09-26 10:39:38 +0000 document.documentElement.insertAdjacentHTML specs WebKit behavior instead of IE behavior 2011-10-03 15:33:51 +0000 1 1 1 Unclassified WebAppsWG DOM Parsing and Serialization unspecified PC All RESOLVED FIXED https://bugzilla.mozilla.org/show_bug.cgi?id=681052 P2 normal --- 1 hsivonen Ms2ger gavin.sharp jonas mike public-webapps public-webapps-bugzilla oldest_to_newest 57340 0 hsivonen 2011-09-26 10:39:38 +0000 Consider http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1148 It throws in Chrome and per spec. It doesn't throw in IE9 or in Opera 11.51. Given that insertAdjacentHTML is originally an IE API, shouldn't the spec describe IE behavior instead of WebKit behavior? Is there a good reason to throw? 57341 1 jonas 2011-09-26 11:00:35 +0000 "beforebegin"/"afterend" must absolutely throw if you try to insert text or element. But inserting comments or using "afterbegin"/"beforeend" seems ok. In other words, we should remove the explicit throwing if the context is a document, but we should reword the actual insertion of the fragment in terms of calling insertBefore and rethrow any exceptions that that throws. 57342 2 hsivonen 2011-09-26 11:27:51 +0000 (In reply to comment #1) > "beforebegin"/"afterend" must absolutely throw if you try to insert text or > element. The current spec doesn't throw if the parent is null, either. > But inserting comments or using "afterbegin"/"beforeend" seems ok. WebKit doesn't support it. > In other words, we should remove the explicit throwing if the context is a > document, but we should reword the actual insertion of the fragment in terms of > calling insertBefore and rethrow any exceptions that that throws. There's little value in being able to insert comments or whitespace using insertAdjacentHTML, but supporting that case would add complexity. We'd need to deoptimize the "afterend" case in Gecko when insertAdjacentHTML is invoked on the root element. Is being able to insert comments really worth the trouble compared to keeping the spec as-is or making the parent-is-document case return silently without doing anything? 57365 3 jonas 2011-09-26 20:25:15 +0000 (In reply to comment #2) > (In reply to comment #1) > > "beforebegin"/"afterend" must absolutely throw if you try to insert text > > or element. > > The current spec doesn't throw if the parent is null, either. That seems like a bug in the spec. > > But inserting comments or using "afterbegin"/"beforeend" seems ok. > > WebKit doesn't support it. Which "it"? And it's not immediately clear why webkit not supporting it matters? > > In other words, we should remove the explicit throwing if the context is a > > document, but we should reword the actual insertion of the fragment in > > terms of calling insertBefore and rethrow any exceptions that that throws. > > There's little value in being able to insert comments or whitespace using > insertAdjacentHTML, but supporting that case would add complexity. We'd need > to deoptimize the "afterend" case in Gecko when insertAdjacentHTML is > invoked on the root element. Is being able to insert comments really worth > the trouble compared to keeping the spec as-is or making the > parent-is-document case return silently without doing anything? I'm not sure what you mean by "deoptimize". A good implementation strategy seems to be to detect when parsing into the document node (which can happen for innerHTML, outerHTML and insertAdjecentHTML). In gecko this requires a single inlined flag check, so not a performance problem for the common case. When parsing into the document node, use a fragment as parsing target and then insert the fragment using insertBefore or other appropriate DOM method and rethrow any exceptions that that throws. 57393 4 hsivonen 2011-09-27 07:31:00 +0000 (In reply to comment #3) > (In reply to comment #2) > > (In reply to comment #1) > > > "beforebegin"/"afterend" must absolutely throw if you try to insert text > > > or element. > > > > The current spec doesn't throw if the parent is null, either. > > That seems like a bug in the spec. The spec is describing an existing feature and implementations that predated the spec didn't throw in that case. > > > But inserting comments or using "afterbegin"/"beforeend" seems ok. > > > > WebKit doesn't support it. > > Which "it"? Inserting comments outside the root element using insertAdjacentHTML. > And it's not immediately clear why webkit not supporting it > matters? It's an indicator that sites probably don't try to insert comments above the root element too much using insertAdjacentHTML(). > > > In other words, we should remove the explicit throwing if the context is a > > > document, but we should reword the actual insertion of the fragment in > > > terms of calling insertBefore and rethrow any exceptions that that throws. > > > > There's little value in being able to insert comments or whitespace using > > insertAdjacentHTML, but supporting that case would add complexity. We'd need > > to deoptimize the "afterend" case in Gecko when insertAdjacentHTML is > > invoked on the root element. Is being able to insert comments really worth > > the trouble compared to keeping the spec as-is or making the > > parent-is-document case return silently without doing anything? > > I'm not sure what you mean by "deoptimize". I mean having to have yet another check before we decide whether we can parse directly into the context node. > A good implementation strategy seems to be to detect when parsing into the > document node (which can happen for innerHTML, outerHTML and > insertAdjecentHTML). In gecko this requires a single inlined flag check, so not > a performance problem for the common case. > > When parsing into the document node, use a fragment as parsing target and then > insert the fragment using insertBefore or other appropriate DOM method and > rethrow any exceptions that that throws. But why bother doing any of this compared to not letting anything be inserted before or after the root element? Is there a use case that Web authors really need addressed here? 57703 5 Ms2ger 2011-10-03 15:33:51 +0000 I am told that document.documentElement.insertAdjacentHTML("beforebegin", "<div></div>") adds a second element child to the document in IE8 and IE9, and throws (per spec) in IE10, and that it throws in the null-parent case as well. That is, IE appears to match Gecko. After discussion with Henri, I went with throwing in both cases. https://bitbucket.org/ms2ger/dom-parsing-and-serialization/changeset/ee0ba6d66250