I'd lean slightly towards option 2 at this point, convinced by the argument that it's an unnecessary side-effect of the feature. But I believe they are both workable solutions.

This is exactly how I feel on this one too, fwiw. But either solution is workable, and I don't really see this as a big enough issue to delay the spec, if it comes to that

While I'm sympathetic to the argument that it should hew closer to Nesting (thus option 1), I think Option 2 is indeed the better behavior. I think the simpler we can keep specificity, the better, and indeed the scope-proximity already provides a similar behavior as increased specificity anyway.

Drawing a parallel with @container which also targets a certain parent element (albeit by name) the specificity of the targeted boundary should not be taking into account and option 2 seems like the way to go.

But … that makes me doubtful of the position of @scope in the cascade (strong vs weak).

Say you have this:

header a { /* (0,0,2) */
  color: hotpink;
}

@scope (nav) {
  a { /*(0,0,1) with Option 2*/
    color: lime;
  }
}

With weak scoping, links matching header nav a would be hotpink instead of lime, no? That might be pretty unexpected, I think.

That might be pretty unexpected, I think.

Second guessing myself: depends on how you look at the “problem”. Is the goal of the author to color the links in the header similarly, or is the goal to be able to drop a nav element/component just anywhere in the DOM and have it look the same? 🤔

Personally, I can't confirm that scopes adding to the specificity is more intuitive.

Either way of handling this seems easy enough to build a mental model around:

In the yes case, one can think of the upper boundary as a sort of fancier descendant selector, as that is, in a sense, what the scope does.

In the no case, one can think of scopes the same way as media queries: They only restrict when or where a rule applies.

The latter seems a bit more consistent to me, because

1. @scope looks similar to @media, so I expect it to work in a similar way.
2. Unless prefixed with :scope, selectors inside the scope's block aren't entirely nested inside the scope. This breaks the mental model of concatenating the selectors anyway.

From a practical perspective, I don't see much value in having scopes change specificity, as that is needless overlap with @layers in my view. The two can be easily combined.

From a practical perspective, I don't see much value in having scopes change specificity, as that is needless overlap with @layers in my view. The two can be easily combined.

Yup, this was gonna be my point as well. Ultimately, a lot of the composition issues are meant to be solved by layers. Trying to solve composition in specificity is imo doomed to failure; specificity is already often very complex for authors, and it serves multiple purposes; stretching it to do even more just makes it more difficult to use in general, even if it solves one particular case slightly more elegantly. (But I'd push back on that as well, tbh.)

Just to get on the record: I was surprised that it was speced to add specificity, and I thought it seemed to me less intuitive and less good. However, this was not and is not a very strongly held position. I think I find it personally more intuitive that it not include specificity by default, I think that specificity is already complex. That said, I am just one sample and guessed that like most things like this if we could poll the whole world, we'd probably be ~ evenly split and the more important thing is to ultimately just choose one and not get stuck on that :)

My intuition is also to not add the specificity of the scope rule. I think our goal with scoping and layers should be to give authors tools other than specificity to control the cascade, so using it for scoping would counter that direction...

(Specificity is a heuristic. I think it works well in a lot of cases, and that's why we have it, but it's still a heuristic. It would be better if authors had better tools for explicit control over the cascade, imho.)

The CSS Working Group just discussed [css-cascade-6] The specificity of a scope rule, and agreed to the following:

• RESOLVED: the specificity of the scope root is not applied to selectors from scoped rules