It took me a while to even get what the point of this issue is because I just assumed that to <selector> would mean <selector> is not included in the scope anymore. I definitely think the lower boundary should be exclusive.

It doesn't seem to me that there is a universally right choice for this. In most of my CSS use-cases, I would want to define boundaries that are part of the scope (inclusive - also used by Vue), but it's also clear the exclusive approach makes more sense with some component-nesting cases. I hope we don't end up supporting one over the other. We need the choice available for authors to express both

I like the fact that exclusive boundaries leave that choice open to an extent (via boundary > * selectors), but I think we might want some more explicit way of expressing that choice.

For every application I have for CSS scopes, it would make more sense to have an exclusive lower boundary. Usually one knows the first element down the tree that should be outside the scope, like a nested component.

But I also think that both options should be available. While boundary > * would semantically be equivalent to an inclusive boundary, giving it its own keyword would both make the code look nicer and signal to the browsers that both options should be reasonably optimised (I can imagine the direct child selector being slower when not specifically optimised)

However, the obvious question is whether mixing the two should be allowed; that is, having a scope end exclusively at one selector or inclusively at another.

Say we wanted to exclude anything with an ID from the scope, and any child element from a nested component, but while keeping the component inside the scope; would this be valid: @scope (my-component) to (container-component) until ([id])?

Of course, there'd still be the fallback of doing @scope (my-component) until ([id], container-component>*) in that case, but that has the same problems as not having an implicit boundary in general.

Another way to approach this that would allow for both-at-once is to say 'lower boundaries are exclusive by default unless explicitly marked with the :boundary pseudo-class' (actual name tbd). Then:

@scope (.component) to (.lower) {
  div { /* does not match div.lower */ }
  div:boundary { /* does match div.lower */ }
}

@scope (.component) to (.lower) {
  div { /* does not match div.lower */ }
  div:boundary { /* does match div.lower */ }
}

Would that div:boundary only select the div.lower then? If so, wouldn't that mean one would have to duplicate every selector, like outer-element > inner-element.some-class + p, outer-element > inner-element.some-class + p:boundary?

But this also leads to another question: Should boundary inclusion be defined per boundary, or per selector?

Personally I would argue that the pseudo-class approach is a bit counterintuitive, since normally a pseudo-class narrows a selector rather than expanding it:

div { /* matches all divs */ }
div:last-child { /* narrows selection to divs that are the last child */ }

I would find it much more natural if it was part of the scope itself — either with something like an exclusive keyword...

@scope ([data-scope='main-component']) to ([data-scope]) exclusive {...}

...or, if exclusive were the default (which I would definitely advocate for, partly given my own use cases but mostly because inclusive semantics can be expressed with exclusive semantics but not vice versa):

/* this... */
@scope ([data-scope='main-component']) to ([data-scope]) inclusive {...}

/* ...is sugar for this */
@scope ([data-scope='main-component']) to ([data-scope] > *) {...}

I like the idea of having an inclusive keyword, but it seems very easy to miss at the end; maybe it would be better like this:

@scope ([data-scope='main-component']) to inclusive ([data-scope]) {...}

This is a bit easier to figure out than to vs. until which seem a bit harder to remember which is which. I also think making exclusive the default makes a lot of sense.

I agree that keywords are likely the clearest path forward here.

So the options we currently have are:

1. @scope (.a) to (.b) vs. @scope (.a) until (.b)
2. @scope (.a) to (.b) inclusive vs. @scope (.a) to (.b) exclusive
3. @scope (.a) to inclusive (.b) vs. @scope (.a) to exclusive (.b)

Leaving aside the question of which should be the default in 2. and 3., here's my thoughts on each of them:

1. For myself I'd choose this one, as it's shortest and saves unnecessary typing, but "to" and "until" are often used interchangeably in casual language so this may also be the most confusing.
2. This one is definitely easier to remember as the words have very clear definitions, but I can't find any specific advantage to putting these keywords at the end.
3. I slightly lean towards this one because it makes the keyword a bit more visible when reading the rule.

In the case of 2. and 3., the question of which should be the default when neither keyword is used could be decided at a later moment. That way the question could already be narrowed down a lot.

I also think option 3 makes the most sense. Agenda+ to see if we can resolve on that (or one of the others).

I don't have very strong feelings about this, any of 1,2,3 seem totally usable to me, but... When you're looking at a range, inclusive or exclusive feels secondary to the selectors, which will in all probability look a lot more like @Rich-Harris's examples - as those get more complex than .a or .b, I wonder if it gets just a little harder to scan them if there is some 'noise' between them that is kind of secondary. It's pretty minor, probably, but because of this I sort of think I prefer them in the order they are listed, pretty much.

If we keep the 'Selector Scoping Notation' we would also need to solve this problem in that syntax, which is currently ( <scope-start> [/ <scope-end>]? ).

@mirisuzanne Would be nice if we can keep the two syntaxes somehow consistent.

I agree. We could technically merge the two syntaxes completely. The 'Selector Scoping Notation' would fit fine in an at-rule (the other direction is a bit more difficult). In that case we don't have parenthesis to separate the two selector lists, and keywords (to/until) are indistinguishable from element selectors, so we use a symbol. The two most obvious solutions from there are either:

1. A different symbol for inclusive/exclusive (for example, using / for inclusive and // for exclusive)

/* inclusive scope rule */
@scope ([data-scope='main-component'] / [data-scope]) { .a { ... } }

/* exclusive selector syntax */
([data-scope='main-component'] // [data-scope]) .a { ... }

2. A function name on the outer parenthesis

/* inclusive scope rule */
@scope inclusive([data-scope='main-component'] / [data-scope]) { .a { ... } }

/* exclusive selector syntax */
exclusive([data-scope='main-component'] / [data-scope]) .a { ... }

Since the selector syntax requires a symbol anyway, I lean towards giving that symbol some power (option 1) to keep things compact. But option 2 has the advantage of being more explicit. Also open to other options here.

The CSS Working Group just discussed Inclusive vs exclusive lower boundary.

Just a quick idea: Considering how (foo) to inclusive (bar) is the same as (foo) to exclusive (bar) > *, it might be easier for the short hand syntax using slash to simply use that instead:

(.post / .comment) .title { font-size: 2em; } /* Exclusive */
(.post / .comment > *) .title { font-size: 2em; } /* Inclusive */

So I'm starting to think that maybe selector scope notation should always be exclusive. For one, the shorter syntax already looks a lot more esoteric than a @scope rule with to as a separator, so there's also less reason to express exclusivity vs. inclusivity with an expressive keyword.

And > * has the advantage of already being a known CSS idiom, which imo makes it better than the / vs // distinction which is completely new.

As for the idea of using the slash syntax for @scope rules, while I like the consistency that would bring, I really hate how esoteric the slash looks compared to the to keyword. On the other hand, / is used to mean "to" in other places already, like in grid grid-row / grid-column.

p { grid-column 1 / 2; }

So here's what I would currently consider ideal:

@scope (outer-component) to (inner-component) {}
/* Default exclusive, to be consistent with selector notation */
@scope (outer-component) to exclusive (inner-component) {}
/* Redundant, as exclusive would be default, but more explicit for devs who don't want to bother remembering the default */
@scope (outer-component) to inclusive (inner-component) {}

(outer-component / inner-component) h1 { font-size: 2em } /* Exclusive by default */
(outer-component / inner-component > *) * { color: red; }

(outer-component /> inner-component) * { color: red; }

I'd like to bring this back for a proposed resolution on the following:

• The default behavior is for lower boundaries to be excluded from scope
• We will provide inclusive and exclusive keywords in the @scope syntax
• The keyword comes after the selectors

Depending on the resolution of #7709, the selector scoping notation may become irrelevant, or it can be handled manually as shown by @DarkWiiPlayer in the previous comment. I don't believe this should be blocked because we can't think of a shorthand for something that's already possible in a syntax we're not even sure we need.

The CSS Working Group just discussed lower boundaries, and agreed to the following:

• RESOLVED: make exclusive lower boundaries the default and add an example to the spec on how to do inclusive

For now:

• lower boundaries are excluded from a scope
• authors can use .lower-boundary > * to generate 'inclusive' lower boundaries
• additional syntax can be added if there is developer need

Closing this issue. We can open a new issue for the keywords (or reopen this) if we decide there is enough need.

Just throwing in another random thought:

Should there be some explicit way of styling the lower boundary?

Something along the lines of

@scope ([data-scope="main-component"]) to ([data-scope]) {
   /* Generally, we do not want to style the lower boundary; probably the most common case */
   * { color: red; }
   /* occasionally we might want to explicitly include the lower boundary too */
   *+*, *+:lower-boundary { margin-top: 1em; }
}

Is there a better way around it with what we currently have? Is this worth opening its own issue for?

I think for now the solution is defining multiple scopes:

/* Generally, we do not want to style the lower boundary; probably the most common case */
@scope ([data-scope="main-component"]) to ([data-scope]) {
   * { color: red; }
   /* occasionally we might want to explicitly include the lower boundary too */
   *+*, *+:lower-boundary { margin-top: 1em; }
}

/* occasionally we might want to explicitly include the lower boundary too */
@scope ([data-scope="main-component"]) to ([data-scope] > *) {
   *+* { margin-top: 1em; }
}

Similar to keywords for exclusive/inclusive, we could consider extra syntax sugar for that case once we have a better sense how the feature is being used.