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

On Thu, May 10, 2012 at 9:28 PM, Rafael Weinstein <rafaelw@google.com>wrote:

> On Thu, May 10, 2012 at 4:19 PM, Ian Hickson <ian@hixie.ch> wrote:
> > On Thu, 10 May 2012, Rafael Weinstein wrote:
> >> On Thu, May 10, 2012 at 4:01 PM, Ian Hickson <ian@hixie.ch> wrote:
> >> > On Fri, 11 May 2012, Tab Atkins Jr. wrote:
> >> >
> >> > 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 [...]
> >>
> >> [...[ 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";
> >
> > My proposal would return a single option element with the value "One".
> >
> > But the example here suggests a different use case. There are presumably
> > three elements there, not one. If this is a use case we want to address,
> > then let's go back to the use cases again: what is the problem we are
> > trying to solve? When would you create a document fragment of some
> > options, instead of just creating a <select> with options?
>
> BTW, for example
>
> In handlerbars,
>
> <select>
>  {{# each optionListThatComeInPairs }}
>    <option>{{ firstThingInPair }}
>    <option>{{ secondThingInPair }}
>  {{/ each }}
> </select>
>
> Or equivalently, in MDV
>
> <select>
>  <template iterate="optionsListThatComeInPairs">
>    <option>{{ firstThingInPair }}
>    <option>{{ secondThingInPair }}
>  </template>
> </select>


To clarify, this doesn't suffer from the string concatenation problem that
Ian was worried about, right? {{ firstThingInPair }} is inserted as a
string, not HTML, right? Similarly, if you had 'data-foo="{{ attributeValue
}}"', it would be escaped appropriately so as to avoid any possibility of
XSS?

Ojan