[whatwg] HTML parsing, the stack of open elements, and foreign content

[Rafael Weinstein]

I just opened another similar bug:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=21292 which has a
similar root cause.

I agree with Adam that it seems wrong that the stack of open elements
can contain elements in disparate namespaces, but its operation (at
times) only examines the local name (e.g. checking if an element is in
a specific scope, popping elements from the stack of open elements
until an element with the same tag name...)

On Wed, Feb 27, 2013 at 12:39 PM, Adam Klein <adamk at chromium.org> wrote:
> Consider the following script:
>
> tr = document.createElement('tr')
> tr.innerHTML = '<math><tr><mo><td>';
>
> That is, the fragment is parsed with tr as the context element. What
> should the generated DOM be? Note that <mo> is a "MathML text
> integration point", which causes the <td> to be processed not as
> foreign content but as a normal HTML token. This leads to the
> following DOM in WebKit:
>
> <tr>
>     <math math>
>         <math tr>
>             <math mo>
>     <td>
>
> (the "math" prefixes denote that these are elements with the MathML
> namespace.) In Gecko, I instead get:
>
> <tr>
>     <math math>
>         <math tr>
>             <math mo>
>             <td>
>
> Note that the <td> in both cases is an HTML element, even though in
> Gecko it's in a MathML tree.
>
> The spec for what should happen to that <td> is the first step of
> http://www.whatwg.org/specs/web-apps/current-work/multipage/tree-construction.html#parsing-main-intr
>
> This case clearly seems like a bug in Gecko: it's treating the <math
> tr> as if it's an HTML <tr>. That is, it's comparing only the local
> name (or "tag name" as the spec usually refers to it).
>
> But this same ambiguity exists elsewhere in the spec. For example, the
> very next item under "in row" says "If the stack of open elements does
> not have an element in table scope with the same tag name as the
> token" (in this case, it's looking for a <tr>).
>
> I think the HTML parser ought to specify more precisely how to deal
> with namespaces in the stack of open elements, given that that stack
> can contain elements of varying namespaces.
>
> - Adam