[go: nahoru, domu]

Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[css-cascade] Opt-in strong proximity for @scope #8601

Open
DarkWiiPlayer opened this issue Mar 16, 2023 · 3 comments
Open

[css-cascade] Opt-in strong proximity for @scope #8601

DarkWiiPlayer opened this issue Mar 16, 2023 · 3 comments

Comments

@DarkWiiPlayer
Copy link

The current consensus on #6790 seems to be that weak proximity is generally preferable for @scoped 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 :links, 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.

@romainmenke
Copy link
Member

#6790 (comment)

so it essentially just creates a two-class system for styling rules, which is really hard to work with

That was exactly my point in #6790 (comment)

Strong proximity scoping might feel similar as @layer but the opt-in or toggle mechanic would again introduce this two-class system, which again would be really hard to work with.

The issue with !important is that some action at a distance changes the rules/context you have to work in.

@DarkWiiPlayer
Copy link
Author

But just like @layers, it's not a two-tier system, because you can stack as many of them as you like. While there is no !importantererer, you can always create a new, inner strong @scope that further overrides the rules of the (now) middle scope, and you can always override scoped rules with unscoped rules in a higher @layer, so everything done by a strong @scope is extensible and reversible, unlike !important rules used to be (again, for lack of an !importanter keyword, that was a one-time override).

@romainmenke
Copy link
Member
romainmenke commented Mar 16, 2023

Different two-tier system :)

With !important authors get stuck with why isn't my declaration being applied?
Once someone at a distance used !important you are forced to also add !important (specificity still applies). This escalates until you end up with !important everywhere.

The same would be true with @scope.
Any mode toggle that makes something have more weight will force others to also add more weight to override the thing that you gave more weight.

How you add more weight is a factor, but it is not the core issue.
It is that you have to add weight because someone else (at a distance) added weight.

you can always create a new, inner strong @scope that further overrides the rules of the (now) middle scope

Exactly.
It forces others to also use a strong @scope.
A weak @scope would no longer work.

@mirisuzanne mirisuzanne added this to Discussions in Cascade 6 (Scope) Dec 11, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Development

No branches or pull requests

3 participants