Re: [csswg-drafts] [css-cascade] Custom Cascade Layers (formerly "custom origins") (#4470)

> As stated over in a comment on the gist, "order" means standard stylesheet ordering, the same ordering used for the final specificity tiebreaker and many other features (such as "last-defined" for @Keyframes with the same name). So there's no race conditions here. If an early stylesheet loads late, it'll just insert its defined layers into the appropriate spot in the ordering, not append to the end.

I think you're referring to [this comment](https://gist.github.com/mirisuzanne/4224caca74a0d4be33a2b565df34b9e7#gistcomment-3417239). Agree that it clears my concern about race conditions. There is though the (lesser, but real) concern about flipping ordering during load causing style thrashing.

> > I have a concern about how well this proposal satisfies the use case of importing common third-party styling libraries.
> 
> I'm pretty sure this is also caused by confusion over the race condition thing, and thus isn't actually an issue. Is this right?

My concern was regarding this comment I made in the gist: about how to avoid the main site knowing about the third-party layer names ([this comment](https://gist.github.com/mirisuzanne/4224caca74a0d4be33a2b565df34b9e7#gistcomment-3416944)). @lilles mentioned a [related concern](https://gist.github.com/mirisuzanne/4224caca74a0d4be33a2b565df34b9e7#gistcomment-3417239).

As @tabatkins  mentioned to me offline, I think my main concern is alleviated because the main stylesheet can wrap any third-party imported stylesheet in an anonymous or named layer, and then make sure to declare that layer at the right place relative to other main stylesheet layers.



> I don't think this is easily compatible with predefined layers. I mean, we _could_ do it, but it would be weird. We'd have to define a specific position for the predefined layer, and either add some more complex syntax to let custom layers go above or below it, or just put all custom layers in a specific position relative to it. I don't want to do the first, and the second means, in practice, that people just shouldn't use the predefined layer at all once custom layers are supported (since it's unlikely that the predefined name, if it fits in their name system at all, is appropriate to be at the start/end of their other layers).

If we first ship one or more predefined layers, and then later ship custom-definable layers, then yes the ordering relative to the predefined layers would probably be fixed. However, this would just mean the site should at that point stop using the predefined layers and use custom layers only, if it conflicted with their desired order, and then the ordering of predefined layers relative to custom layers doesn't matter, because the site doesn't use them. If the site included a third-party stylesheet that utilized the predefined layers, then it could be imported with a wrapping anonymous or named layer placed at the appropriate ordering position; this situation seems the same as the one in my earlier comment above.

Therefore I do think it's backwards compatible. If predefined layers are specified and shipped first, this has the following advantages as I see it:
* Avoids having to implement definition of extensions of imports for `@import`, `link` and `style tags`, or the nested layer concatenation and ordering features 
* Avoids all of the potential developer gotchas referenced on the gist having to do with nested layers
* Reduced complexity of understanding the feature for developers
* (maybe?) Encourages shared CSS design patterns involving layers among different libraries, thereby making it easier for sites to adopt these libraries without learning new layer names and best practices.


-- 
GitHub Notification of comment by chrishtr
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4470#issuecomment-677874012 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Thursday, 20 August 2020 20:00:54 UTC