W3C home > Mailing lists > Public > public-html-bugzilla@w3.org > September 2010

[Bug 10314] "in cell" (secondary) insertion mode shows strange behavior for e.g. <table><tr><td><svg><td></td><td>, <table><tr><td><svg><tbody></tbody>

From: <bugzilla@jessica.w3.org>
Date: Fri, 10 Sep 2010 19:20:08 +0000
To: public-html-bugzilla@w3.org
Message-Id: <E1Ou98q-0002Zb-V3@jessica.w3.org>
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10314


Ian 'Hixie' Hickson <ian@hixie.ch> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |eric@webkit.org,
                   |                            |hsivonen@iki.fi,
                   |                            |ian@hixie.ch,
                   |                            |w3c@adambarth.com




--- Comment #1 from Ian 'Hixie' Hickson <ian@hixie.ch>  2010-09-10 19:20:08 ---
I assume you mean <table><tr><td><svg><desc><td>?

I guess the solution is to make it clear that "reprocess the current token"
means that we should first check the rule in the "in foreign content" section
that resets the insertion mode, before then rerunning the token through the
entire system from the top?

There is also the problem with <table><tr><td><svg><td><desc><td>. Not sure how
to handle that one, unless we start checking for namespaces when looking at tag
names. Any suggestions?

We could probably solve both problems by making <svg> scoping for table scope,
but then we'd have to add a bunch of error-handling logic in the table modes.

Or maybe the real problem is that the secondary mode can be anything but "in
body". Should we give up with the secondary mode idea, and just reset the
insertion mode when exiting foreign lands, and always defer to the in-body mode
from foreign lands when appropriate?

-- 
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 Friday, 10 September 2010 19:20:10 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:24 UTC