[csswg-drafts] [css-cascade] Opt-in strong proximity for @scope (#8601)

DarkWiiPlayer has just created a new issue for https://github.com/w3c/csswg-drafts:

== [css-cascade] Opt-in strong proximity for @scope ==
The current consensus on #6790 seems to be that *weak proximity* is generally preferable for `@scope`d style rules, meaning that stronger selectors from outer scopes can override rules in inner scopes.

I'd like to discuss the merit of adding a mechanism for CSS authors to promote scopes to strong proximity for cases where the alternatives are either much too cumbersome or just not viable altogether:

1. Layers have a global order in which they apply, so one scope could be made to categorically override another, but that might not be enough when it is unknown to the CSS author which element will be the inner and which the outer scope.
2. Lower boundaries are only usually viable to scopes of the same type, like `@scope ([theme="dark"]) to ([theme])` but are a poor solution for unrelated scope types that want to override similar rules.

One such example that I often encounter when writing CSS is that different sections of a website should have different styles for `:link`s, where a link in a `nav` is usually identifiable as a clickable link from context, whereas links in paragraphs need to be styled differently (usually underlined and/or different font colour) for the user to identify them as such.

This gets complicated when, for example a `nav` may appear inside a `p` in one instance, but a `p` may also appear inside a `nav` (in the form of, say, a side-panel brought up by a hamburger button at the end of a `nav` bar with some text at the bottom)

One proposed syntax for this is an added exclamation mark `@scope! (nav) { /* ... */ }`, but another obvious option would be a key-word like `@scope strong (nav) { /* ... */ }`

To keep the discussion on point, I'd ask to not go too deep into *is it at all possible to do without this by clever usage of layers and lower boundaries* but to focus instead on the actual viability of such work-arounds and whether it's reasonable to add this as an easier and more maintainable way of getting the job done.

Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8601 using your GitHub account


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

Received on Thursday, 16 March 2023 11:20:08 UTC