W3C home > Mailing lists > Public > public-script-coord@w3.org > January to March 2013

Re: E4H and constructing DOMs

From: Brendan Eich <brendan@secure.meer.net>
Date: Sat, 09 Mar 2013 15:59:25 -0800
Message-ID: <513BCCDD.5030101@secure.meer.net>
To: Ojan Vafai <ojan@chromium.org>
CC: Adam Barth <w3c@adambarth.com>, Domenic Denicola <domenic@domenicdenicola.com>, Allen Wirfs-Brock <allen@wirfs-brock.com>, Jonas Sicking <jonas@sicking.cc>, Anne van Kesteren <annevk@annevk.nl>, Rick Waldron <waldron.rick@gmail.com>, Adam Klein <adamk@chromium.org>, Ian Hickson <ian@hixie.ch>, "rafaelw@chromium.org" <rafaelw@chromium.org>, Alex Russell <slightlyoff@chromium.org>, "public-script-coord@w3.org" <public-script-coord@w3.org>, "Mark S. Miller" <erights@google.com>
Ojan Vafai wrote:
> 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.

This is a productive suggestion. Thanks -- we will discuss it at next 
week's Ecma TC39 meeting, I've added it to the agenda.

> 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.

One stage's static is another's dynamic. We could allow early errors but 
not mandate them. Another agenda item -- thanks again.

/be
>
> Ojan
>
>
>     Adam
>
>
>     On Fri, Mar 8, 2013 at 6:04 PM, Domenic Denicola
>     <domenic@domenicdenicola.com <mailto:domenic@domenicdenicola.com>>
>     wrote:
>     > From: Adam Barth [mailto:w3c@adambarth.com
>     <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>`;
>     >
>     > 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. 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 `{}`.
>     >
>     > Look forward to hearing what I missed!
>
>
Received on Sunday, 10 March 2013 00:00:03 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 May 2013 19:30:09 UTC