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

> 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.

Right, so at that point we're defining something that we *know* will be obsoleted almost immediately, but will provide a footgun (in the form of a name that authors aren't allowed to use) forever. Do we believe authors are clamoring for a solution that can be well-solved by a single predefined layer *so hard* that we think it's worthwhile to throw away effort like that?

> Avoids all of the potential developer gotchas referenced on the gist having to do with nested layers

I just reread the gist and couldn't find any gotchas listed about nested layers. Can you elaborate?

> Reduced complexity of understanding the feature for developers

Yes, a single predefined layer is simpler than multiple layers. But we're gonna move to arbitrary named layers anyway; they can't avoid that complexity. And having both a predefined layer and arbitrary layers makes the entire feature slightly more complex than it would otherwise be, so in the end it's slightly worse, not neutral.

> (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.

I think this one's a stretch, yeah.  Even with only *one* layer, there's still at least two completely distinct and very reasonable ways to use them that would cause bad clashes between libraries: with the layer as reset/defaults and unlayered code as normal, or with the layer as "normal" and the unlayered code as spot-overrides ("better !important").

GitHub Notification of comment by tabatkins
Please view or discuss this issue at using your GitHub account

Sent via github-notify-ml as configured in

Received on Thursday, 20 August 2020 22:31:18 UTC