w3c / w3c/csswg-drafts

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

Open
#8,601 3 comments 4 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

css-cascade-6
Dominant language
Bikeshed
Stars
4.9k
Forks
816
PR merge metrics
PR metrics pending

Description

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.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with issue #6790 and this issue's three comments to understand the current weak-proximity consensus. Compare the proposed @scope! and @scope strong forms against layers and lower boundaries using the nested nav/p examples; done would require a resolved CSSWG decision on whether and how to standardize the opt-in behavior.

Written by the indexing model from the issue text.

Assessment

Tech stack
css
Domain
frontend
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
20/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.