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

Re: E4H and constructing DOMs

From: Mike Samuel <mikesamuel@gmail.com>
Date: Sun, 10 Mar 2013 15:02:02 -0400
Message-ID: <CACod6GvSy+497Xx+C=osZu-HbtzYqnGKsayvYEFD9hyAjiBdmA@mail.gmail.com>
To: Ojan Vafai <ojan@chromium.org>
Cc: Adam Barth <w3c@adambarth.com>, Domenic Denicola <domenic@domenicdenicola.com>, Allen Wirfs-Brock <allen@wirfs-brock.com>, Jonas Sicking <jonas@sicking.cc>, Anne van Kesteren <annevk@annevk.nl>, Rick Waldron <waldron.rick@gmail.com>, Adam Klein <adamk@chromium.org>, Brendan Eich <brendan@secure.meer.net>, Ian Hickson <ian@hixie.ch>, "rafaelw@chromium.org" <rafaelw@chromium.org>, Alex Russell <slightlyoff@chromium.org>, "public-script-coord@w3.org" <public-script-coord@w3.org>, "Mark S. Miller" <erights@google.com>
2013/3/9 Ojan Vafai <ojan@chromium.org>:
> On Sat, Mar 9, 2013 at 8:58 AM, Adam Barth <w3c@adambarth.com> wrote:
>> Specifically, I would be perfectly happy with the following syntax:
>> header.appendChild(`<h1>Welcome ${ firstName } ${ lastName }!</h1>`);
>> as long as this "hello, world" template is not XSS.
> 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).

I don't think Adam's example requires producing a DOM, just producing
a value from which appendChild can extract a DOM node.  In my attempt
to bolt safe string interpolation onto EcmaScript, I consciously
produced a string-like value instead of a string so that a string sink
could supply context when converting the string-like value to an
actual string with properly escaped interpolations.  Adam's example
does not preclude a similar approach.

This is one of the problems with comparing vaporware to a concrete
implementation -- you end up glossing over hard design trade-offs when
counting the pros of the first, but count them as cons against the
Received on Sunday, 10 March 2013 19:02:29 UTC

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