- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Thu, 26 Apr 2012 10:23:39 -0700
- To: Simon Pieters <simonp@opera.com>
- Cc: Ryosuke Niwa <rniwa@webkit.org>, Yehuda Katz <wycats@gmail.com>, Rafael Weinstein <rafaelw@google.com>, Webapps WG <public-webapps@w3.org>
On Thu, Apr 26, 2012 at 1:26 AM, Simon Pieters <simonp@opera.com> wrote: > On Wed, 25 Apr 2012 21:39:53 +0200, Rafael Weinstein <rafaelw@google.com> > wrote: >> Any other HTML tagName => HTMLBodyElement > > Isn't this one redundant with the last step? No, this captures known HTML tagnames, so that HTML can lay claim on the few tags that overlap with SVG. The last step just captures any remaining tags that fell through the cracks, so they can become HTMLUnknownElements. >> Any other SVG tagName => SVGElement >> Any other MathML tagName => MathElement > > What are these two, exactly? The parser currently doesn't have a list of > SVG/MathML tag names, and the SVG WG didn't like it when it was proposed to > use a fixed list of SVG tag names for parsing SVG in text/html, IIRC. We don't need a specific list in the spec, but each browser would need one, constructed from whatever elements they currently understand. (In my dreams, we just merge SVG into the HTML namespace, and then this step disappears.) > Also note that innerHTML on non-HTML elements currently always parses in the > "in body" insertion mode. I'd like to see that fixed before we try to > support foreign content in contextless innerHTML. > > https://www.w3.org/Bugs/Public/show_bug.cgi?id=16635 Yes, that needs to be fixed. As Ms2ger said yesterday in IRC, the DOMParsing spec already handles this appropriately, but HTML needs a a fix, since the former hooks into the latter. ~TJ
Received on Thursday, 26 April 2012 17:24:37 UTC