Re: E4H and constructing DOMs

On Sat, Mar 9, 2013 at 5:43 PM, Maciej Stachowiak <mjs@apple.com> wrote:

> On Mar 9, 2013, at 2:21 PM, Ojan Vafai <ojan@chromium.org> wrote:
>
> 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.
>

The E4H algorithm doesn't use the HTML parser. It translates what is
basically XML to a bunch of appendChild/setAttribute calls. This has the
advantage of being simple and also allowing you to create whatever sort of
DOM that you could from script. None of the HTML context rules. The
alternative would be to use the HTML parser in the a context-free mode. I
don't remember the result of the million discussions we had about this for
the <template> element and whether that would work for this use-case. As
you say, if we were to use the HTML parser, then there couldn't be any
static error checking.

On Sat, Mar 9, 2013 at 7:15 PM, Maciej Stachowiak <mjs@apple.com> wrote:
>
> On Mar 9, 2013, at 6:26 PM, Brendan Eich <brendan@secure.meer.net> wrote:
>
> Allen Wirfs-Brock wrote:
>
> On Mar 9, 2013, at 5:29 PM, Brendan Eich wrote:
>
> No, the idea Ojan put forth is that the tag-less form should call a
> default handler other than String, in browsers. Specifically it would do a
> checked form of HTML parsing that threw if interpolations were not complete
> and well-formed subtrees.
>
>
> Platform specific processing for tag-less string templates would be
> terrible for cross platform interoperability.
>
>
> You mean portability.
>
>
> I think Ojan's proposal was to have *no* tag-less string templates, which
> wouldn't have a portability issue.
>

This is what I meant, but I'd be fine with any of these options. I buy
Adam's argument that the default handler returning a string is an
unnecessary footgun.

I'd also be fine with just shipping E4H.


> Another possibility is to have no tag-less string templates in the core
> language, but add them only for the browser-hosted binding, pointing to an
> AST-based HTML template that returns a DOM tree.
>
> I suspect that even for many non-browser-hosted applications of JS, string
> templating with a very convenient syntax would be a security footgun. I
> would expect this to be true for Node.js, certainly.
>
> Regards,
> Maciej
>
>