Re: Custom element design with ES6 classes and Element constructors
> 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 upgrade scenario can't really be expressed by > coupled alloc+init if it preserves object identity, right? Yes, and it seems to me that we are trying to hack around the fact that ES6 classes are not compatible with what we are trying to do. Would it be naive to request a well defined way to change an objects class post alloc? It seems like a hard problem, but I can imagine pure JS cases too when it would make sense to do a transformation. And if there is no official way to do it people will start to try and hack their way through in 1000 horrible ways... (+ internally I'm sure most engines does transformations in some cases already, like for array optimisations...) - Gabor
Re: [Imports]: Styleshet cascading order clarification
- Original Message - > From: "Tab Atkins Jr." > To: "Gabor Krizsanits" > Cc: "Hajime Morrita" , "public-webapps" > > Sent: Monday, November 3, 2014 7:12:27 PM > Subject: Re: [Imports]: Styleshet cascading order clarification > > On Mon, Nov 3, 2014 at 7:28 AM, Gabor Krizsanits > wrote: > > 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). And the consensus > > was that we > > should just not allow global styles in imports. > > > > Some months has passed but I still don't see any update on the spec. in > > this regard, > > so I'm just double checking that we still planning to do this or if > > anything changed > > since then. > > Out of curiosity, why is it hard? Without much background in the > implementation matters, it doesn't seem that a that > contains a should be any different than a rel=stylesheet> that contains an @import rule. > > ~TJ > See my comments here: https://www.w3.org/Bugs/Public/show_bug.cgi?id=24756 I think the difference is the de-duping mechanism in HTML imports. Importing the same import from multiple places in the import graph can change the import order hence the underlying style-sheet order too. So just because link import A is before link import B in the document does not necessary say anything about the order of their stylesheet... My concern is that in complex projects it will be even harder to track down css related issues, given that adding an extra link to the import tree can significantly change the order of the imports. The other concern is performance related. We will have to rearrange the rules all the time the import graph changes during the import parsing. But one could argue that it's just an implementation detail... Then again, maybe all these issues can be outweighed by some important use cases... - Gabor
[Imports]: Styleshet cascading order clarification
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). And the consensus was that we should just not allow global styles in imports. Some months has passed but I still don't see any update on the spec. in this regard, so I'm just double checking that we still planning to do this or if anything changed since then. - Gabor
[imports] Spec. polishing
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 notes. Some of these nits are just personal opinion, so I don't expect all of them to be addressed but I guess it helps if I mention them. I'm not a native English speaker so I have not tried fixing grammar mistakes. - import referrer section does not reflect the fact that there can be more referrer for an import (the referrer -> one of the referrers) - for master document might be easier defined as the one and only root node of the import graph - what's up with the defaultView these days? is it shared? is it null? is it decided? - "imported documents don't have a browsing context" - isn't it more precise that it's using the master documents browsing context? - "import dependent" is used before defined - import parent/ancestor : I would define parent first and then extend it to ancestor. also worth mentioning that the import link list are the sub imports list for clarification - it's extremly hard to see that script execution order is really defined, even when I know how it is defined... figuring it out from the current spec without any prior knowledge is... challanging to say the least. I think a detailed walk through on the graph would be a HUGE help. By that I mean explicitly defining the execution order for the example, and also maybe illustrating at some stages, what is blocking what. - missing link to 'simple event' Gabor
Re: [HTML imports]: Imports and Content Security Policy
> 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 CSP3 does not. So what should we do with I4? If I2 comes first it will allow I4 to be loaded and then I3 will get it as well, even though it should not. If I3 comes first then it won't be loaded... But let's say we eliminate the ordering problem by loading I4 and for I3 we just return null for the import something. What about: I1 | | I2 I3 | | I4 | | I5 I6 Now let's say CSP2 allows I5 but not I6 and CSP3 allows both I5 and I6 (or even worse allows I6 but not I5). Now it we look at I5 from I2 we should get a different imported document than looking at it from I3... To fix this problem we can just completely ignore the parents CSP when we determine if a sub import should be loaded or not. But I think that would kind of defeat the purpose of having CSP on the first place... Anyway, maybe I'm missing something but I don't see how the original "own CSP" could work.
[HTML imports]: Removing imports
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 reloaded. Question is, when to remove the import from the cache (let's call it import manager). One version is to release import documents when the master document is released. Another would be to wait until all the link elements that refers to it are released. But maybe it should be released the moment the last referring link element is detached from the tree... this way users could force re-try import loading. Because right now, if import loading failed, there is no way to re-try it. Any thoughts?
Re: [HTML imports]: Imports and Content Security Policy
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 inline scripting either... I think this should be mentioned in the spec. Since if you develop some huge library let's say, based on imports, and then no costumer can use it who also want to have CSP, because it's full of inline scripts, that would be quite annoying.
