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

On Thu, May 10, 2012 at 4:01 PM, Ian Hickson <ian@hixie.ch> wrote:
> On Fri, 11 May 2012, Tab Atkins Jr. 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'll go ahead and anticipate your response of "they should just use the
>> Element.create() API"
>
> That would indeed be my response.
>
>
>> while Element.create() is great, it solves a different use-case.  Being
>> able to construct DOM from raw HTML is easy to read and write and
>> understand, particularly when it's a static fragment (or a concatenation
>> of mostly static fragments), while Element.create() requires a
>> translation into a JS API with a much different syntax. Element.create()
>> is much more readable and writable when you're making some DOM out of a
>> *lot* of dynamic information.
>>
>> In other words, this:
>>
>> $("<div class=foo><img src="+foosrc+"></div>")
>>
>> is a lot easier than:
>>
>> Element.create("div", {class: "foo"}, [ Element.create("img", {src: foosrc}) ]);
>>
>> So, that's the use-case for this API.
>
> The idea of building elements using string concatenation is a security
> disaster. What if "foosrc" above contains '" onclick="...' ?
>
> But ok, let's assume that the use case is "create an element and its
> subtree so that you can insert dynamically generated parts of an
> application during runtime", e.g. inserting images in a dynamically
> generated gallery, and security by damned.
>
> If we're going to do that, then we don't need any lookahead at all. We
> should support literally that: parsing one element and its descendants. We
> determine what element is being generatd by looking at the top of the
> string ("<div ..." -> it's a div, "<tr ..." -> it's a tr, etc), and we
> parse until that element is popped from the stack or the end of the string
> is reached. This avoids all the problems with doing magical lookahead.

This was more or less Yehuda's original proposal. If we can make this
work, I think it also solves the problem and would be acceptable. My
sense is that this solution probably introduces more complexity into
the parser and it's output isn't any superior.

Anne pointed out that accomplishing this isn't straightforward. I
forget what his examples were (I think they had to do with poorly
formed markup), but here's one that comes to mind which is valid
markup: What's the output for this

myDocFrag.innerHTML = "<option>One<option>two<option>three";

>
>
> But I'm very skeptical about creating new APIs to encourage authors to use
> injection-prone, non-type-checked, direct string manipulation in script to
> generate DOM trees.
>
> --
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Thursday, 10 May 2012 23:16:01 UTC