W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2012

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

From: Rafael Weinstein <rafaelw@google.com>
Date: Fri, 11 May 2012 05:21:01 -0700
Message-ID: <CABMdHiQbkUzphZ4QYcgg_UEFDBxuu9q1ta7RJ3+qSk5n9kt63A@mail.gmail.com>
To: Ojan Vafai <ojan@chromium.org>
Cc: Ian Hickson <ian@hixie.ch>, Webapps WG <public-webapps@w3.org>
On Fri, May 11, 2012 at 12:13 AM, Ojan Vafai <ojan@chromium.org> wrote:
> 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?

Correct. In the first example, handlebars will escape the script
before doing innerHTML, and MDV doesn't invoke the parser, it assigns
the Text node's textContent.

>
> Ojan
Received on Friday, 11 May 2012 12:21:33 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:52 GMT