- From: Henri Sivonen <hsivonen@iki.fi>
- Date: Fri, 11 May 2012 11:55:27 +0300
- To: Rafael Weinstein <rafaelw@google.com>
- Cc: Webapps WG <public-webapps@w3.org>, Yehuda Katz <wycats@gmail.com>
On Wed, May 9, 2012 at 7:45 PM, Rafael Weinstein <rafaelw@google.com> wrote: > I'm very much of a like mike with Henri here, in that I'm frustrated > with the situation we're currently in WRT SVG & MathML & parsing > foreign content in HTML, etc... In particular, I'm tempted to feel > like SVG and MathML made this bed for themselves and they should now > have to sleep in it. I think that characterization is unfair to MathML. The math working group tried hard to avoid local name collisions with HTML. They didn't want to play namespace games. As I understand it, they were forced into a different namespace by W3C strategy tax arising from the "NAMESPACE ALL THE THINGS!" attitude. SVG is the language that introduced collisions with both HTML and MathML and threw unconventional camel casing into the mix. On Fri, May 11, 2012 at 1:44 AM, Tab Atkins Jr. <jackalmage@gmail.com> wrote: > The innerHTML API is convenient. It lets you set the entire > descendant tree of an element, creating elements and giving them > attributes, in a single call, using the same syntax you'd use if you > were writing it in HTML (module some extra quote-escaping maybe). I'm less worried about magic in an API that's meant for representing tree literals in JavaScript as a sort of E4H without changing the JavaScript itself than I am about magic in APIs that are meant for parsing arbitrary potentially user-supplied content. If we are designing an API for the former case rather than the latter case, I'm OK with the following magic: * Up until the first start tag parser behaves as in "in body" (Tough luck if you want to use <![CDATA[ or U+0000 before the first tag, though I could be convinced that the parser should start in a mode that enables <![CDATA[.) * if the first start tag is any MathML 3 element name except "set" or "image", start behaving as if setting innerHTML on <math> (details of that TBD) before processing the start tag token further and then continue to behave like when setting innerHTML on <math>. * otherwise, if the first start tag is any SVG 1.1 element name except "script", "style", "font" or "a", start behaving as if setting innerHTML on <svg> (details of that TBD) before processing the start tag token further and then continue to behave like when setting innerHTML on <svg>. * otherwise, set the insertion mode per HTML-centric <template> rules proposed so far. Open question: Should it be possible to use a magic attribute on the first tag token to disambiguate it as MathML or SVG? xmlns="..." would be an obvious disambiguator, but the values are unwieldy. Should xlink:href be used as a disambiguator for <a>? If the use case is putting tree literals in code, it probably doesn't make sense to use <script> or <style> (either HTML or SVG) in that kind of context anyway. And SVG <font> has been rejected by Mozilla and Microsoft anyway. I still think that having to create a DocumentFragment first and then set innerHTML on it is inconvenient and we should have a method on document that takes a string to parse and returns the resulting DocumentFragment, e.g. document.parse(string) to keep it short. -- Henri Sivonen hsivonen@iki.fi http://hsivonen.iki.fi/
Received on Friday, 11 May 2012 08:55:57 UTC