On Mar 9, 2013, at 5:38 PM, Maciej Stachowiak wrote:
>
> On Mar 8, 2013, at 6:04 PM, Domenic Denicola <domenic@domenicdenicola.com> wrote:
>
>> From: Adam Barth [mailto:w3c@adambarth.com]
>>
>>> Right, that's why the example in my first email is XSS:
>>
>>> var firstName = [...];
>>> var lastName = [...];
>>> header.innerHTML = `<h1>Welcome ${ firstName } ${ lastName }!</h1>`;
>>
>>> Whereas the E4H equivalent would not be:
>>
>>> var firstName = [...];
>>> var lastName = [...];
>>> header.appendChild(@<h1>Welcome { firstName } { lastName }!</h1>);
>>
>>
>> I must be missing something, but from my reading you are not gaining anything in the ES4H example over the string templates example, if of course you modify the last line to be
>>
>> header.innerHTML = html`<h1>Welcome ${ firstName } ${ lastName }!</h1>`;
>
> Can quasi handlers return non-strings? A built-in html quasi handler could be a lot safer if it could return a DOM tree instead of a string, i.e.
>
> header.appendChild(html`<h1>Welcome ${ firstName } ${ lastName }!</h1>`);
>
> This way the handler could be internally AST-based and would not have to reserialize back to a string.
yes they can
>
>>
>> In particular, as has been explained in this thread a few times, there's no reason why browsers can't ship a built-in `html` template handler that does the same AST-based DOM parsing on the passed template string that ES4H would do on the source string following the @-sign, and subsequently returns the `outerHTML` of the resulting DOM element.
>
> Not all DOMs can be safely round tripped through serialization and reparsing.
>
>> Indeed, since string templates don't even need to return strings, you could do
>>
>> header.appendChild(htmlel`<h1>Welcome ${ firstName } ${ lastName }!</h1>`);
>
> This is what html`` should do, if there is such a built-in quasi handler, IMO.
+1
>
> Regards,
> Maciej
>