12434 2011-04-06 08:52:15 +0000 Spec doesn't match IE when calling insertAdjacentHTML with position afterend or beforebegin on head or body 2011-09-05 10:42:35 +0000 1 1 1 Unclassified WebAppsWG DOM Parsing and Serialization unspecified All All RESOLVED FIXED needs testcase P2 normal --- 1 hsivonen Ms2ger ayg ian jonas mike public-html-admin public-html-wg-issue-tracking public-webapps public-webapps-bugzilla oldest_to_newest 47192 0 hsivonen 2011-04-06 08:52:15 +0000 http://software.hixie.ch/utilities/js/live-dom-viewer/saved/918 IE9, IE8 and IE6 (IE7 not tested) behaves as if the context node for fragment parsing in the insertAdjacentHTML case was "body" when it logically should be "html". Since it's their API originally, I think it would be prudent to codify this quirk in the spec. Note that there is precedent: The same quirk exists in Range::createContextualFragment. 47193 1 hsivonen 2011-04-06 08:54:33 +0000 This should only apply to the HTML case, not the XML case. 47205 2 jonas 2011-04-06 13:58:32 +0000 Are there pages that depend on this? 47206 3 jonas 2011-04-06 13:59:12 +0000 Also, does this affect both how content gets parsed and where it gets inserted? Or just how content gets parsed. 47207 4 hsivonen 2011-04-06 14:19:05 +0000 (In reply to comment #2) > Are there pages that depend on this? I don't know. (In reply to comment #3) > Also, does this affect both how content gets parsed and where it gets inserted? > Or just how content gets parsed. This affects parsing only. Specifically, it affects the creation of implicit head and body nodes. 50575 5 ian 2011-07-01 22:21:32 +0000 What do other browsers do today? 51059 6 ian 2011-07-14 22:23:26 +0000 Is there a test case showing the difference? I'd like to study this in other UAs before making a decision on this. 53844 7 mike 2011-08-04 05:33:45 +0000 mass-move component to LC1 56334 8 Ms2ger 2011-09-05 10:42:35 +0000 https://bitbucket.org/ms2ger/dom-parsing-and-serialization/changeset/a5d7da5a4f86 Henri, could you confirm this is the correct fix?