Re: [csswg-drafts] [css-cascade] What are the proper "levels" for managing Cascade Layers? (#4969)

I'd add one more use case: polyfilling for browsers that don't yet support cascade layers.

It seems to me that it would suffice to define exactly one new layer, and define it via an `@baselayer` @ rule. This would sit in the cascade between the user agent rules and all regular developer stylesheet rules. Within a style sheet, it would look like:

```
@baselayer {
  .foo { position: relative !important } /* Can't be overridden by regular rules not in @baselayer */
  :where(.foo) { background: blue } /* Can be overridden by regular rules with non-zero specificity */
}

.foo { position: absolute !important } /* Has no effect due to above */
.foo{ background: red } /* Changes blue to red */
```

The second layer would be just the usual CSS layer for a developer's style sheet.

Referring back to @AmeliaBR's use cases:

* *3rd party library with essential and default styles*: this would work by having the library put essential styles in the `@baselayer` with `!important` and default theming styles without it and zero specificity. The page that uses the 3rd-party library would then add rules as desired to override theming styles.

* *Importing/linking multiple 3rd-party stylesheets (resets, components, basic themes), and wants to organize them by priority*: can't be done without coordination or pre-processing tools. IMO this is ok not to solve, since solving it may introduce a lot of complexity or lead to the problem of the 4th use case.

* *Concatenating multiple stylesheets*: works fine because order of rules doesn't matter and multiple `@baselayer`s can be concatenated together.

* *Multiple 3rd-party components declare origins with conflicts*: can't happen because there is no way to define two layers.

* *Polyfilling*: can be done with an approach like the following:

1. A polyfill would insert a `@baselayer {}` stylesheet in front of any other stylesheets. This should be doable in SSR and lazy-loaded environments.
2. The `@base-layer` selectors would have to be at the lowest available specificity, e.g. using `:where`.
2.a. Alternatively, since it's not likely that most use cases can take advantage of tag-name selectors, it means that as much as possible `@baselayer` has to rely on selectors that consist of a single class or a single attribute.
2.b. In few use cases such as `.mycheckbox[checked]` a more specific selector could be warranted, b/c a user would be naturally expected to use a similar or higher specificity for overriding.
2.c. Perhaps a polyfill can warn a developer when a more complicated selector is used in the `@baselayer`, which would make it harder to override in the user stylesheet. And then it can be left up to the developer to decide if the risk of using a non-polyfillable scenario is worth it.

@dvoytenko


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

Received on Friday, 24 July 2020 16:01:30 UTC