w3c / w3c/csswg-drafts

[css-cascade-6] `:scope` scoping root node clarification

Open
#9,739 3 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Closed Accepted as Editorial css-cascade-6 Needs Edits
Dominant language
Bikeshed
Stars
4.9k
Forks
816
PR merge metrics
PR metrics pending

Description

I did recently add a test for one :scope use case: https://github.com/web-platform-tests/wpt/pull/43697

When approving it, @mdubet mentioned a thing that led me to go and test how :scope behaves in the current WebKit implementation:

To my understanding of the spec, the inner rule selector should be :is(:scope .b):is(:scope.x *) with :scope representing any .a elements of the page.

To me, the “any .a elements” sounds incorrect. Per the current specs (https://drafts.csswg.org/css-cascade-6/#scope-effects):

The :scope selector is defined to match the @scope rule’s scoping root.

As I think it is intended, and as it is currently implemented in Chrome, the :scope in this case should match “The scoping root node” (quoting the specs), with the “node” being important, and meaning it should not match just any similar scoping root.

However, the current implementation in Safari Technology Preview seems to treat it as something similar to :where(&) (with the specificity of a pseudo-class), here is a CodePen with an example: https://codepen.io/kizu/pen/WNmeLre

HTML & CSS for this example
<div class="root outer">
  <div class="test">this should be lightgreen</div>
  <div class="limit">
    <div class="root">
      <div class="test inner">this should be lightgreen</div>
    </div>
  </div>
</div>
@scope (.root) to (.limit) {
  .test {
    background: lightgreen;
  }

  /* This should never match for our HTML structure */
  :scope.outer .test.inner {
    background: tomato;
  }
}

In Chrome, we can see two light-green elements, but in Safari TP the second one is tomato.

I think the way it works in WebKit is due to the misinterpretation of the spec. If this is a case, maybe the spec could be clarified? I think, the minimal clarification could be to add the “node” wording to the :scope's definition, but perhaps a more verbose explanation of what this should mean in practice (could be as a note?) could be added as well.

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 CSS Cascade 6’s scope-effects section and the linked Selectors 4 scoping-root definition. Review the WPT case in PR 43697, then compare the Chrome and Safari Technology Preview behavior shown in the CodePen. Done means the specification clearly states which node :scope matches, with an appropriate clarification or note.

Written by the indexing model from the issue text.

Assessment

Tech stack
css
Domain
documentation
Issue type
Documentation
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.