- From: Rafael Weinstein <rafaelw@google.com>
- Date: Thu, 26 Apr 2012 21:58:49 -0700
- To: "Tab Atkins Jr." <jackalmage@gmail.com>, Henri Sivonen <hsivonen@iki.fi>
- Cc: Simon Pieters <simonp@opera.com>, Ryosuke Niwa <rniwa@webkit.org>, Yehuda Katz <wycats@gmail.com>, Webapps WG <public-webapps@w3.org>
Henri, Does this address the concerns you raised earlier? On Thu, Apr 26, 2012 at 10:23 AM, Tab Atkins Jr. <jackalmage@gmail.com> wrote: > 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 Friday, 27 April 2012 04:59:19 UTC