Re: [xhr-1] XMLHttpRequest Level 1 WD update

2014-01-30 Thread Arthur Barstow
On 1/27/14 11:41 PM, ext Jungkee Song wrote: Thanks for all the comments. I've updated the WD of XMLHttpRequest Level 1 as such: https://dvcs.w3.org/hg/xhr/raw-file/tip/xhr-1/TR/Overview.html FYI, the new WD was published earlier today http://www.w3.org/TR/2014/WD-XMLHttpRequest-20140130

Re: [HTML imports]: Imports and Content Security Policy

2014-01-30 Thread Gabor Krizsanits
One more thing that little bit worries me, that the most common request when it comes to CSP is banning inline scripts. If all the imports obey the CSP of the master, which I think the only way to go, that also probably means that in most cases we can only use imports those do not have any

[HTML imports]: Removing imports

2014-01-30 Thread Gabor Krizsanits
I've already opened a bug that import removal is not clear to me (https://www.w3.org/Bugs/Public/show_bug.cgi?id=24003), but there is more... So in one way or another imports are cached per master documents so if another link refers to the same import in the import tree it does not have to be

Re: [HTML imports]: Imports and Content Security Policy

2014-01-30 Thread Scott Miles
I'm hoping there are some constraints we can impose on imports to allow them to contain inline scripts to exist under CSP. Failing that, we already have a tool ('vulcanizer') which can separate scripts out of imports (and to the reverse as well). Whether an import uses inline or external scripts

Re: [HTML imports]: Imports and Content Security Policy

2014-01-30 Thread Nick Krempel
The security objection to the original own CSP design was never fully developed - I'm not sure it's necessarily a show-stopper. Nick On 30 January 2014 18:53, Scott Miles sjmi...@google.com wrote: I'm hoping there are some constraints we can impose on imports to allow them to contain inline

Re: [HTML imports]: Imports and Content Security Policy

2014-01-30 Thread Gabor Krizsanits
The security objection to the original own CSP design was never fully developed - I'm not sure it's necessarily a show-stopper. Nick Well, consider the case when we have the following import tree: I1 | | I2 I3 | | I4 Respectively CSP1, CSP2, CSP3. CSP2 allows I4 to be loaded but

[webcomponents] Async Registration of Custom Elements

2014-01-30 Thread Ryosuke Niwa
Hi, Could someone clarify why we want to allow out-of-order registration of custom elements? Can we also have (a pointer to) concrete use cases for this feature? The thing is if an author wants to replace or customize a placeholder element using a script that loads later, that’s pretty easy

Re: [HTML imports]: Imports and Content Security Policy

2014-01-30 Thread Hajime Morrita
Generally I prefer master-CSP model than the own CSP model due to its simplicity but I agree that unsafe-script kills the conciseness of Imports. To make inline scripts work with imports, we might want another CSP directive like safe-script, which allows parser-made script but doesn't allow

Re: [HTML imports]: Removing imports

2014-01-30 Thread Hajime Morrita
I don't want to make it removable from the cache/manager. Once it is loaded, it should be there until the page ends. Allowing removal/cancellation has big implication that will introduce many complicated race conditions and edge cases. For example, what happens if link is removed before/while its