- From: Henri Sivonen <hsivonen@iki.fi>
- Date: Fri, 11 May 2012 14:13:09 +0300
- To: "Tab Atkins Jr." <jackalmage@gmail.com>
- Cc: Rafael Weinstein <rafaelw@google.com>, Webapps WG <public-webapps@w3.org>, Yehuda Katz <wycats@gmail.com>
On Fri, May 11, 2012 at 12:59 PM, Ryosuke Niwa <rniwa@webkit.org> wrote: > Yes! Can we re-use createDocumentFragment and add an optional argument > instead though? I think that makes sense in principle, but I worried that the name createDocumentFragment is the kind of name that's works OK if you're writing Java into an IDE that has autocompletion but that's super inconvenient in a language that's dynamically typed (so autocompletion can't be exact) and often written without autocompletion. On Fri, May 11, 2012 at 1:09 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote: > Tangent: It appears to be a very difficult uphill battle to get SVG > into the HTML namespace or un-namespaced entirely, but how difficult > might it be to do that for MathML? We can branch this to a separate > thread if the answer is anything other than "Don't even think about > it." Don't even think about it. ;-) >> 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. > > I'm not sure what you mean by the latter. If this translates as > "improving innerHTML is okay with me", then cool. ^_^ I mean that it's a bad if the kind of magic fragment parsing we're introducing here is used with untrusted input the way innerHTML today is used with untrusted input. >> 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[.) > > Ah, so this would mean you just *always* emit the characters before > the first start tag? Yes. >> * 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. > > I think that SVG should get priority over MathML on the conflicts - > <set> and especially <image> are useful SVG elements that can > reasonably be the first tag of a fragment. It seems more useful to > get an svg fragment for an <image> than a mathml fragment. That's what I was trying to say. >> 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. > > SVG is chucking xlink, so that won't work. In SVG2, <a> will just use > @href. Surely SVG2 has to support xlink:href in order to support existing content. > If we did want to use a magic attribute, I suggest @svg and @math as > boolean attributes with no effect other than this disambiguation (and > then just resolving all conflicts in HTML's favor by default). Makes sense. >> 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. > > I agree. We should definitely *have* DocumentFragment.innerHTML, but > we should also have a shorter way of doing so and getting the DOM, > like the document.parse() you suggest. One thing that I particularly dislike about innerHTML is that it changes behavior depending on the HTMLness flag of the owner document (whether it uses the HTML parser or the XML parser). For consistency, we'd probably have to spread of that (Gecko-originating?) design bug to DocumentFragment for completeness if we were to introduce innerHTML on DocumentFragment. A new document.parse(string) or document.createDocumentFragment(string) could always use the HTML parser. However, I'm not strongly opposed to adding innerHTML to DocumentFragment if we also add a method on Document that parses a string using the HTML parser regardless of the HTMLness flag of the document and returns a DocumentFragment (or has an optional extra argument for forcing XML parsing explicitly). -- Henri Sivonen hsivonen@iki.fi http://hsivonen.iki.fi/
Received on Friday, 11 May 2012 11:13:44 UTC