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?

(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.

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.)

(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.)

We could make setting innerHTML throw (NotSupportedError or InvalidAccessError?) in HTML if the context node's namespace isn't one of the three, maybe?

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.

Getting doesn't need to throw.

No browser implements MathML DOM interfaces AFAIK. Elements in the MathML namespace use Element.

Only one browser implements MathML at all, as far as I can tell.
So that doesn't say much.

I think this should either be WONTFIX or reassigned to DOM to move innerHTML off Element.

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.

innerHTML is not defined in DOM.