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. > > ~TJReceived on Friday, 27 April 2012 04:59:19 UTC
This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:33 UTC