- From: Rafael Weinstein <rafaelw@google.com>
- Date: Sat, 16 Jun 2012 10:11:07 +0300
- To: Ian Hickson <ian@hixie.ch>
- Cc: Adam Barth <w3c@adambarth.com>, Webapps WG <public-webapps@w3.org>
E4H doesn't address all the use cases of Document.parse(). It doesn't solve the problem of existing templating libraries constructing DOM fragments from processed templates. E4H (or something similar) would be great, but I think it's a mistake to make it mutually exclusive with Document.parse(). On Tue, Jun 5, 2012 at 11:24 PM, Ian Hickson <ian@hixie.ch> wrote: > On Mon, 4 Jun 2012, Adam Barth wrote: >> > >> > http://www.hixie.ch/specs/e4h/strawman >> > >> > Who wants to be first to implement it? >> >> Doesn't e4h have the same security problems as e4x? > > As written it did, yes (specifically, if you can inject content into an > XML file you can cause it to run JS under your control in your origin with > content from the other origin). However, as Anne and you have said, it's > easy to fix, either by using an XML-incompatible syntax or using CORS to > disable it. Since we have to disable it in Workers anyway, I'd go with > disabling it when there's no CORS. Strawman has been updated accordingly. > > > On Tue, 5 Jun 2012, Anne van Kesteren wrote: >> >> A (bigger?) problem with E4H/H4E is that TC39 does not like it: >> http://lists.w3.org/Archives/Public/public-script-coord/2011OctDec/thread.html#msg33 > > What matters is what implementors want to do. The TC-39 spec process isn't the problem here. TC-39 is composed of implementors, and they are clearly stating a preference for quasis. > > -- > Ian Hickson U+1047E )\._.,--....,'``. fL > http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. > Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Saturday, 16 June 2012 07:11:38 UTC