I think this part of the spec was largely written before ES6 class stuff stabilized, fwiw. Which is not hard, since it's still not stabilized. ;) Isn't there a chance to consider our use-case in ES6 spec. then? Basically, ES6 is moving toward coupling allocation and initialization but the
- Original Message - From: Tab Atkins Jr. jackalm...@gmail.com To: Gabor Krizsanits gkrizsan...@mozilla.com Cc: Hajime Morrita morr...@google.com, public-webapps email@example.com Sent: Monday, November 3, 2014 7:12:27 PM Subject: Re: [Imports]: Styleshet cascading order
During our last meeting we all seemed to agree on that defining/implementing order for style-sheets is imports is super hard (if possible) and will bring more pain than it's worth for the web (aka. let's not make an already over-complicated system twice as complicated for very little benefits).
I've heard complains about the readability of the current import draft, and I think the best way to improve it, if we all take some time and point out the parts that could benefit from some polishing. Instead of filing a dozen of tiny bugs, I just went through the spec. again and took some
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
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
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