[css-cascade-6] clarification of :scope matching in nested scopes

[kizu]

While testing different ways scopes interact when being nested, and how :scope behaves inside them in both Chrome and Safari Technology Preview, I found a difference in how the browsers treat the :scope when there are nested scopes present.

Here is a CodePen with the example: https://codepen.io/kizu/pen/xxBxKao

HTML & CSS for this example

<div class="outer">
  <div class="inner">
    <div class="test">this should be lightgreen</div>
    <div class="test never">this should be lightgreen</div>
    <div class="test unwrapped">this should be lightgreen</div>
  </div>
</div>

@scope (.outer) {
  .test {
    background: red;
  }
  
  @scope (.inner) {
    :scope.inner .test {
      background: lightgreen;
    }
    
    /* This should never match */
    :scope.outer .test.never {
      background: tomato;
    }
  }
}

@scope (.outer .inner) {
  :scope.inner .unwrapped {
    background: lightgreen;
  }
}

I consider the way it works now in Chrome (the :scope matches the innermost closest defined scope) as correct. I did not find anything in the specs (https://drafts.csswg.org/css-cascade-6/#scope-scope) outside example 8, which shows the scope equivalence, where the :scope matches the inner scoping root.

Given how Safari currently uses the topmost scoping root instead, I think it would be nice to clarify the behavior of the :scope inside nested scopes explicitly in the normative parts of the spec, so there will be less left for interpretation.

[andruud]

I consider the way it works now in Chrome (the :scope matches the innermost closest defined scope) as correct.

This was behavior was always the intent, we just need an editorial change here IMO.

[bramus]

This was addressed in 180fce4, no?

… the [=scoping root=] is defined by the innermost ''@scope''.

[mdubet]

The spec, Chrome and Safari all seem to have the same behaviour here (:scope matches the scoping root of the innermost @scope)

[mirisuzanne]

It seems like we might be able to close this as a browser bug that's been fixed (question answered)? I'm not sure we need any resolution. @fantasai you added the agenda+ label - was there something more that needed discussion on this?

[kizu]

Testing it in the latest Safari TP — it seems things now behave the same as in Chrome, and the spec edit seems sufficient, so it is ok to close this issue and remove from the agenda.