Re: E4H and constructing DOMs

I'd like to understand the round-tripping concerns for quasis. One option
here is to have DOM implement a template processor (aka "quasi") [1] that
is effectively the parser's view of the world (much like E4H). Since DOM is
just standard library addons for JS, this would be relatively natural;
although I can understand that not tagging the string can lead to encoding
issues.

[1] http://tc39wiki.calculist.org/es6/template-strings/

On Thursday, March 7, 2013, Ojan Vafai wrote:

> I found out today that there is more opposition to E4H (
> http://www.hixie.ch/specs/e4h/strawman) than I had previously realized. I
> thought it was just blocked on implementors finding the time to implement
> it. Some people prefer quasis (
> http://wiki.ecmascript.org/doku.php?id=harmony:quasis) as the solution.
>
> Here's how I see the tradeoffs.
>
> Quasis: More generic and meets other string interpolation use-cases.
> E4H: Gives static error checking (e.g. can tell if you if you type
> <div></dv>).
>
> Adam Barth had some security related concerns with the quasis approach
> related to round-tripping strings through the HTML parser.
>
> I don't feel too strongly about which one we implement. In fact, I'd be
> happy if we did both. That is, we do E4H for constructing DOMs and quasis
> for other string interpolation needs.
>
> However, I would like for there to be a path most implementors are happy
> with so that we can finally solve this problem. It's sad that the state of
> the art for constructing DOMs is still $('<div>' + possibleXSSVector +
> '</div>').
>
> For reference, the previous relevant discussions on this topic:
>
> http://lists.w3.org/Archives/Public/public-script-coord/2011OctDec/thread.html#msg65
>
> http://lists.w3.org/Archives/Public/public-script-coord/2011OctDec/thread.html#msg33
>
> http://lists.w3.org/Archives/Public/public-webapps/2012AprJun/thread.html#msg1067
>
> Ojan
>