W3C home > Mailing lists > Public > public-css-archive@w3.org > August 2020

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

From: Tab Atkins Jr. via GitHub <sysbot+gh@w3.org>
Date: Thu, 20 Aug 2020 00:32:05 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-676828679-1597883524-sysbot+gh@w3.org>
> the potential for race conditions (example).

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.

> whether developers will find it too confusing or difficult to debug,

This example is arguing against being able to import a sheet into a layer. Is this because of the temporal race condition confusion? Is it resolved now that it's clear there aren't race conditions?

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

> This proposal does seem to be backward-compatible with an incremental implementation and shipping approach, along the lines of what I suggested here, which is great. (We'd pre-define certain built-in layers, not allow defining new ones, and not support url import syntax.)

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

GitHub Notification of comment by tabatkins
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4470#issuecomment-676828679 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 00:32:08 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 06:42:13 UTC