Re: E4H and constructing DOMs

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