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

E4H and constructing DOMs

From: Rick Waldron <waldron.rick@gmail.com>
Date: Thu, 7 Mar 2013 11:25:08 -0500
Message-ID: <CAHfnhfoTA0WBkfs0vu21mpg9TXCONkOVP6AhW2AjRVcmtss+hA@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>
On Wednesday, March 6, 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.

Template Strings (formerly known as quasis) are already accepted and part
of the ES6 draft.

E4H is a language level syntax extension that appears to duplicate the
functionality provided by Template Strings, while restricting usage to a
web/DOM-centric concept (CORS same-origin or Worker context)—effectively
creating a "version". It also uses one of the remaining unambiguous ascii
characters "@". Granted, it's an interesting experiment, but Template
Strings are capable of "all this and more".

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

Why would you claim this is the state of art? I'm a jQuery maintainer,
caring for both source and docs, and I've never recommended this practice
(certainly no other jQuery maintainer would either). Furthermore, if this
was possible, I'd consider it a bug and we'd patch it accordingly. If you
can produce an example, please report here: http://bugs.jquery.com


> 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 16:25:59 UTC

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