This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 10418 - Scoping element inside e.g. <mi> causes insertion mode to switch to secondary insertion mode too early
Summary: Scoping element inside e.g. <mi> causes insertion mode to switch to secondary...
Status: RESOLVED FIXED
Alias: None
Product: HTML WG
Classification: Unclassified
Component: pre-LC1 HTML5 spec (editor: Ian Hickson) (show other bugs)
Version: unspecified
Hardware: PC All
: P2 critical
Target Milestone: ---
Assignee: Ian 'Hixie' Hickson
QA Contact: HTML WG Bugzilla archive list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-08-24 13:11 UTC by James Graham
Modified: 2010-10-04 14:57 UTC (History)
5 users (show)

See Also:

Attachments

Description James Graham 2010-08-24 13:11:50 UTC 
Consider e.g. <math><mi><object><span></span></object><mi>

The </span> will be processed using the rules for "any other end tag" in the "In Foreign Content" mode. Once this is processed, there will be no element in scope with a namespace other than the HTML namespace (since <object> is a scoping element), so the insertion mode will switch to In Body. The next <mi> token will then be inserted in the In Body mode and so put in the HTML namespace, not the MathML namespace.
Comment 1 Ian 'Hixie' Hickson 2010-08-24 19:05:38 UTC 
Your example is confusing, because <math><mi><mi> will also put the last <mi> in the HTML namespace. Did you mean to have an end tag or something?
Comment 2 James Graham 2010-08-24 20:46:38 UTC 
Yes, there should be a </mi>

<math><mi><object><span></span></object></mi><mi>
Comment 3 Henri Sivonen 2010-09-10 11:55:41 UTC 
What are the cases where we'd want the tree builder to be in the "in foreign content" mode when the current element on the stack is in the HTML namespace?

If we never really want that, I think we should lose "in foreign content" as an insertion mode and lose the secondary mode concept and check whether the element on the stack is not in the HTML namespace whenever we currently check if the tree builder is in the "in foreign content" mode.
Comment 4 Ian 'Hixie' Hickson 2010-09-26 21:01:42 UTC 
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Accepted
Change Description: see diff given below
Rationale: I fixed this by not making foreign lands depend on scoping, and by instead resetting the insertion mode regularly. In practice you can optimise this quite a bit if you try (by having the rest of the parser mark the insertion mode as dirty when the stack is changed in ways that affect the reset algorithm, and only resetting when it's dirty, for example — but I figured I shouldn't do that in the spec since it's just an optimisation, and resetting isn't hugely expensive in most cases anyway).

(In reply to comment #3)
> What are the cases where we'd want the tree builder to be in the "in foreign
> content" mode when the current element on the stack is in the HTML namespace?

The problem isn't really so much that so much as how to handle going _back_ to the foreign lands. I don't think we want to check for foreign lands all the time, that would be bad for perf (I assume foreign lands are relatively rare).
Comment 5 contributor 2010-09-26 21:03:44 UTC 
Checked in as WHATWG revision r5520.
Check-in comment: <math><mi><object><span></span></object></mi><mi>: last <mi> ends up in the wrong namespace
http://html5.org/tools/web-apps-tracker?from=5519&to=5520