On Mar 9, 2013, at 2:21 PM, Ojan Vafai <ojan@chromium.org> wrote:
>
> > Indeed, since string templates don't even need to return strings, you could do
> >
> > header.appendChild(htmlel`<h1>Welcome ${ firstName } ${ lastName }!</h1>`);
> >
> > where `htmlel` just returns an HTML element constructed using that same algorithm (instead of the `outerHTML` of that element).
> >
> > At this point it seems like you are bikeshedding over `@` vs. `htmlel` or `{}` vs. `${}`, which leads me to believe I must be missing your argument, especially since you emphasize you're not wedded to ES4H and thus presumably not wedded to `@` or `{}`.
>
> I don't care at all about the syntax. If you want to keep backtick as
> the operator, that's fine. What's important to me are the following:
>
> 1) The template system parses the trusted template content separately
> from the untrusted input data. In particular, it should fill the
> untrusted data into the leaves of AST produced by parsing the template
> rather than parsing the untrusted data.
>
> 2) The template system does the above by default.
>
> Specifically, I would be perfectly happy with the following syntax:
>
> header.appendChild(`<h1>Welcome ${ firstName } ${ lastName }!</h1>`);
>
> as long as this "hello, world" template is not XSS.
>
> I would imagine that some folks on this list would be resistant to having the default handler be one that produces a DOM instead of a string. Could we have a browser-provided html handler that does E4H style parsing and not have a default handler at all? That way, the simplest code path for developers is to use the browser-provided handler and they have to go out of their way to do something else, but we still leave the door open for other use-cases/handlers (e.g. contextually parsed html).
>
> header.appendChild(`<h1>Welcome ${ firstName } ${ lastName }!</h1>`); // parse error
> header.appendChild(html`<h1>Welcome ${ firstName } ${ lastName }!</h1>`); // E4H style parsing
> header.appendChild(myspecialhtmlparser`<h1>Welcome ${ firstName } ${ lastName }!</h1>`); // template strings as currently proposed
>
> The only thing we lose here I think is an easy way to do multiline strings in JS.
Or how about giving the default handler a name? string`foo` might be less tempting than `foo` compared to html`foo`. It does still leave a footgun lying around, but at least it would not be the default.
> Also, we don't get the static error checking of of E4H. Although, maybe browsers could special case the html handler and do static error checking.
Does the desire for static checking imply that the html`` syntax would only accept valid HTML? Because an HTML parser can parse anything, so I'm not sure in what cases static checking should produce an error.
Regards,
Maciej