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

Re: E4H and constructing DOMs

From: Alex Russell <slightlyoff@chromium.org>
Date: Thu, 7 Mar 2013 03:24:38 -0800
Message-ID: <CANr5HFVQV1kbqQoBDdYPuOUdkRyxc2PyV9o9c1bDOBV_fOqXZg@mail.gmail.com>
To: Ojan Vafai <ojan@chromium.org>
Cc: Adam Barth <abarth@chromium.org>, Ian Hickson <ian@hixie.ch>, "rafaelw@chromium.org" <rafaelw@chromium.org>, Adam Klein <adamk@chromium.org>, Anne van Kesteren <annevk@annevk.nl>, Alex Russell <slightlyoff@chromium.org>, "public-script-coord@w3.org" <public-script-coord@w3.org>
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

[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
Received on Thursday, 7 March 2013 11:25:06 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:08 UTC