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

E4H and constructing DOMs

From: Ojan Vafai <ojan@chromium.org>
Date: Wed, 6 Mar 2013 19:42:26 -0800
Message-ID: <CANMdWTtrMkkAt9k2PWcSwLAfm0OnFLAvovf_KBdpSsOCm+BhZg@mail.gmail.com>
To: Adam Barth <abarth@chromium.org>, Ian Hickson <ian@hixie.ch>, 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 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

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 +

For reference, the previous relevant discussions on this topic:

Received on Thursday, 7 March 2013 03:43:16 UTC

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