Re: [webcomponents] Template element parser changes => Proposal for adding DocumentFragment.innerHTML

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