[Bug 11393] End tag fails to break out of foreign content

http://www.w3.org/Bugs/Public/show_bug.cgi?id=11393

--- Comment #10 from Henri Sivonen <hsivonen@iki.fi> 2011-02-10 10:18:35 UTC ---
(In reply to comment #9)
> I guess it falls to Opera or IE to cast the tie-breaking vote? First one to
> ship something that either matches the spec/WebKit or matches the proposed
> behaviour/Gecko gets to decide what happens?

That's a lousy way to deal with this. Basically, you are leaving a spec bug in
and seeing if implementors take the trouble to realize that the spec is wrong.
Should I counter this by checking in test cases to html5lib in order to make
the implementors notice?

> I don't really know how else to proceed here.

I suggest the following procedure:

 1) Admit that it was a bad idea to prematurely spec optimizations instead of
speccing the intended conceptual model.

 2) Edit the spec to describe the intended conceptual model (which is already
implemented in Gecko in order to avoid having to tweak the code every time we
find yet another failure of your optimization to match the conceptual model).
Basically, "in foreign content" shouldn't be an insertion mode but a check of
the namespace of the current element on the stack in order to decide whether to
handle a start tag token in the foreign lands or according to the insertion
mode.

 3) Leave possible further optimizations in this area to implementations if
they find evidence that optimization is necessary. (I don't have evidence
showing a need to optimize Gecko on this particular point.)

I haven't examined the WebKit implementation closely, but at least for Gecko,
migrating from the spec's flawed optimization to expressing the conceptual
model is code was a relatively straight-forward copy and paste job. However,
going in the other direction would be harder, which is why I don't want to
deliberately break the conceptual model in order to emulate spec bugs.

Note that WebKit's impl isn't up to date for foreign lands changes anyway, so
they need to refresh the code in any case.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Thursday, 10 February 2011 10:18:37 UTC