26804 2014-09-15 10:18:25 +0000 innerHTML on elements that aren't HTML, SVG, or MathML creates elements not in those namespaces 2014-12-01 18:31:39 +0000 1 1 1 Unclassified WebAppsWG DOM Parsing and Serialization unspecified PC All NEW http://software.hixie.ch/utilities/js/live-dom-viewer/saved/3177 P2 normal --- 1 hsivonen travil dtrebbien ian mike www-dom zcorpan public-webapps-bugzilla oldest_to_newest 111512 0 hsivonen 2014-09-15 10:18:25 +0000 Condsider the Blink behavior for http://software.hixie.ch/utilities/js/live-dom-viewer/saved/3177 The element with the local name "bar" ends up in the "bogus" namespace. Surprisingly, this is correct per spec. (The "div" ending up in the HTML namespace is no longer correct per spec; Blink isn't up-to-date with the spec.) Hixie said on IRC that this is unintentional. Please, either make fragment parsing with a non-HTML/SVG/MathML context work like with non-special HTML context or explicitly alert the reader of the spec of the surprising consequence that the fragment parsing algorithm can produces nodes that aren't HTML/SVG/MathML. (FWIW, the parser used in Validator.nu and in Gecko has been written with the assumption that all nodes ever created by the algorithm are in the HTML/SVG/MathML namespaces.) 112088 1 ian 2014-09-24 17:25:15 +0000 So, looking at this more closely, I don't really understand why this wouldn't be expected. Why is it different than if the namespace was SVG? The part of this that is surprising is the part where the author introduces a non-standard namespace into the document, IMHO, not the part where the parser tries its best to muddle along given that environment. What namespace would you want the spec to use, and why? 112235 2 hsivonen 2014-09-26 05:18:21 +0000 (In reply to Ian 'Hixie' Hickson from comment #1) > So, looking at this more closely, I don't really understand why this > wouldn't be expected. Well, I was quite surprised to learn that this is happening, because the algorithm and the history of how it was developed made it look like it dealt with three element namespaces. > Why is it different than if the namespace was SVG? It's not any of the three namespaces the algorithm was *designed* for. > The > part of this that is surprising is the part where the author introduces a > non-standard namespace into the document, IMHO, not the part where the > parser tries its best to muddle along given that environment. What namespace > would you want the spec to use, and why? I want either: 1) The fragment parsing spec to carry an informative warning to implementors that its output isn't limited to the three element namespaces. (I have written code with the assumption that there are only three namespaces. Specifically, with node constructors that don't pass the namespace but have distinct signatures for the three namespaces.) OR 2) The fragment parsing algorithm to put elements in the HTML namespace when the context isn't in any of the three element namespaces that the algorithm cares about. #1 is less work for Blink. #2 is less work for me. #1 arguably makes more sense for authors, but it also opens up more opportunity for weirdness/bugs that neither you nor I have thought about yet. 112286 3 ian 2014-09-26 18:02:29 +0000 Ok, those two options seem reasonable. One other problem with #2 is that it makes it harder to shim the parser when we add new namespaces in the future. For example, say we want to support XSLFO natively. As specced today, this would only require minimal changes (a new element to trigger the foreign lands), and innerHTML would already Just Work, so shims could do it that way. Of course the counter-argument to this is that the odds of us introducing a new namespace to the Web are essentially zero. Another argument against #2 is that it is spec churn. The counter to that is that there's zero content depending on this, probably, since it only comes up when you do innerHTML on namespaced content. An argument against all of this is why on earth are we allowing an API like innerHTML to be applied to non-HTML content. The name doesn't match, plus, it's a horrific API with serious security issues almost as bad as document.write(). Safari doesn't support innerHTML here. This suggests option #3, that we not make innerHTML apply to elements that aren't in the three blessed namespaces. (The reason the spec handles this case as it does is because when it was written, I didn't expect us to move innerHTML to Element, so I never even thought about this issue.) 112442 4 hsivonen 2014-09-30 06:24:57 +0000 (In reply to Ian 'Hixie' Hickson from comment #3) > Safari doesn't support innerHTML here. This suggests option #3, that we not > make innerHTML apply to elements that aren't in the three blessed > namespaces. (The reason the spec handles this case as it does is because > when it was written, I didn't expect us to move innerHTML to Element, so I > never even thought about this issue.) Wouldn't this cause even more churn considering that MathML elements don't have special DOM interfaces? (Also, this option seems impolite to XML if anyone cares about that sort of thing anymore.) 112447 5 zcorpan 2014-09-30 07:58:38 +0000 We could make setting innerHTML throw (NotSupportedError or InvalidAccessError?) in HTML if the context node's namespace isn't one of the three, maybe? 112488 6 ian 2014-09-30 17:37:15 +0000 Seems weird to throw. Why have the API at all, if it just throws? MathML does have a MathMLElement node: http://www.w3.org/TR/MathML2/appendixd.html (Not quite sure what happened to that in MathML3; the intro says that it's in a "separate document" but doesn't seem to cite it.) I don't see why it's impolite to XML. It seems more polite; impolite is the way we're stomping all over virgin namespaces adding global attributes and global APIs, IMHO. 112521 7 zcorpan 2014-10-01 10:57:34 +0000 Getting doesn't need to throw. No browser implements MathML DOM interfaces AFAIK. Elements in the MathML namespace use Element. 112670 8 ian 2014-10-03 21:51:03 +0000 Only one browser implements MathML at all, as far as I can tell. So that doesn't say much. 112980 9 ian 2014-10-11 00:29:45 +0000 I think this should either be WONTFIX or reassigned to DOM to move innerHTML off Element. 114690 10 ian 2014-11-07 21:46:05 +0000 Reassigning to DOM. IMHO innerHTML should just be on HTML elements. There's really no use case for it in the first place; it's a historical security-nightmare API that we should not encourage people to use. 114695 11 annevk 2014-11-07 22:31:48 +0000 innerHTML is not defined in DOM.