Re: E4H and constructing DOMs

2013/3/11 Ian Hickson <ian@hixie.ch>:
> On Fri, 8 Mar 2013, Brendan Eich wrote:
>> Jonas Sicking wrote:
>> > I agree that AST solutions have advantages. But the cost of
>> > introducing them is really high and as far as I can tell there is no
>> > way to create a generic AST-based solution. I.e. if we wanted to do
>> > something SQL-like for querying databases we'd have to invent a whole
>> > new JS syntax for that too.
>>
>> Right. In this sense E4X was on more solid ground, because XML's parsing
>> was simpler and easier to integrate into JS's. E4H is much worse off.
>
> E4H is much simpler than E4X, actually:
>
>    http://www.hixie.ch/specs/e4h/strawman
>
> It's just a small syntax extension to JS. (It doesn't involve an HTML
> parser, in fact it doesn't involve any parser at all other than the JS
> parser, which is why it gives compile-time syntax checking.)

How does it deal with XSS via CSS, URIs, VBScript, etc. without
involving parsers for those languages?

What happens with

    <><a href="{data}">Hello, World!</a></>

when data is "javascript:doEvil()"?

What happens with

    <><style>color: {data}</style></>

when data is "expression(doEvil())"?

What happens with injection into a script?

    <><style>var s = "{data}", re = /{data}/, x = {data};</style></>

?

Received on Monday, 11 March 2013 19:17:08 UTC