Re: E4H and constructing DOMs

Hi Ian, this seems a misunderstanding or non-sequitur. Mike and Rick's
point is not to compromise, it is to do something solid and general
purpose, to avoid injection bugs in a variety of DSL scenarios, not just
HTML. Even in the browser, JS is sometimes used to compose SQL that is sent
to the server. It isn't the browser's business to understand SQL, but we
can provide a mechanism that is as useful for SQL, again, without
compromise.

As for your

> If we're to reserve a prefix like this, we should
> do it sooner rather than later, so we don't get forced into particular
> compat constraints.

I agree completely. And this fits well with the boundary between our
standards organizations. TC39 defines and standardizes a general mechanism
useful across hosting environments. X3C defines some clients of these
mechanisms, standard quasi-parsers for the browser's other languages in
this case (CSS as well, of course).


Adam, I think you miss the point of Mike's message rather completely. This
thousand line JS library has to be done for HTML once, not once per usage.
It is complicated because HTML is complicated. And the amount of code
compares quite favorably to the browser's HTML implementation, which is
much more security critical than this. In any case, if the HTML
quasi-parser is provided by the browser platform as standard equipment, it
can probably reuse some of the browser's existing mechanisms, to help keep
these two HTML systems in sync.

As for whether the output of the HTML quasi-parser is an AST or an encoded
string, that is up to the quasi-parser designer. The quasi-literals in E
generally generated ASTs. Mike convinced me he can generate encoded strings
directly as safely and faster, if the point is to eventually produce an
encoded string. I'm happy either way. Both decisions are perfectly
compatible with the design on quasis, er, template strings, as speced in
draft ES6.




On Thu, Mar 7, 2013 at 6:41 PM, Ian Hickson <ian@hixie.ch> wrote:

> On Thu, 7 Mar 2013, Rick Waldron wrote:
> > On Thu, Mar 7, 2013 at 9:15 PM, Adam Barth <w3c@adambarth.com> wrote:
> > >
> > > Linking to a thousand-line JavaScript library as evidence that string
> > > template can be used securely pretty much proves my point: it's hard
> > > to use string templates securely.  That means that most authors won't
> > > use them securely and will write code that's full of XSS.
> >
> > I'd like to kindly ask that you stop approaching this conversation as
> > though browsers and the web are the only client of the EcmaScript
> > specification.
>
> If we're making compromise decisions that mean that we aren't making the
> absolute best decisions for the Web, then we should fork the language so
> that we can.
>
> (This is not theoretical, we've already done this for IDL and many APIs.)
>
> --
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>



-- 
    Cheers,
    --MarkM