Universal selectors in scoped CSS

[skirtles-code]

TLDR: We currently have special handling for selectors containing *, but I don't know why and I think they should be treated like any other selector.

I've tried to trace the history of how we got to where we are and document it for further discussion of how to proceed.

Introduction

Consider this selector:

div span

This will be compiled to something like:

div span[data-v-111]

The span is the subject of the selector, that's the element that will receive the styles, so we add an extra attribute to ensure it is scoped to the current component.

But we don't add any scoping to the div, and it's been this way for a long time (possibly forever). Ancestors in the selector are not scoped, they don't need to be in the current component.

Now consider this selector:

div *

In Vue 3.5.14, this compiled to:

div[data-v-111] *

This was changed by #12918, so in 3.5.15 we instead get:

div[data-v-111] [data-v-111]

While adding the scoping attribute to the subject does seem like a step in the right direction, I think it should have also been removed from the ancestor, to make it consistent with how we handle div span. I would expect:

div [data-v-111]

Or, equivalently, div *[data-v-111].

This is how it worked in Vue 2. It's also how it worked in Vue 3 prior to 3.4.22. It was changed by #10551, which was a fix for #10548.

However, I don't think #10548 was actually a bug.

The reproduction in #10548 uses a selector of .comp * and notes that the .comp part isn't scoped to the current component, so if an ancestor uses class="comp" it will leak into the current component. But that's true for other selectors too, not just * selectors. If you use .comp div then you'll see the same thing. It's a consequence of only scoping the subject of the selector and not the ancestors. There's nothing special about * here, yet the fix in #10551 singled out * selectors for special treatment.

Perhaps I'm missing something, but this just seems like a misunderstanding.

Specificity

By consistently adding a single attribute to the subject of the selector, we ensure that the specificity of scoped rules, relative to each other, remains the same. The specificity is increased, but always by the same amount.

The change in 3.5.15 increased the specificity for selectors like div *, relative to other scoped selectors. This had led to breakages, e.g. #13401 and #13402.

Nesting

Consider these 3 rules:

.foo * {
  color: red;
}

.foo {
  * {
    color: red;
  }
}

.foo {
  & * {
    color: red;
  }
}

Assuming we're in an environment that supports nesting, these should all be considered equivalent. Tools like PostCSS should be free to treat these as interchangeable and rewrite them as needed. Currently, this is not the case. The second example works as I would expect, replacing the * with [data-v-111], but the others also scope the .foo.

:deep()

:deep() can be used to move the scoping to an earlier part of the selector.

If someone wants a selector of div[data-v-111] * (as generated by div * in 3.4.22 to 3.5.14), they can achieve that using div :deep(*) instead.

[edison1105]

I also don't consider #10548 a bug. Here is a scenario that #10551 did not fix. see demo. I believe we should revert PR #10551 to maintain behavior consistent with Vue 2.

After reverting #10551

• the issue in Star selectors leak scoped styles into children #12906 will be resolved, eliminating the need for fix(compiler-sfc): add scoping tag to trailing universal selector #12918.
• Scoped universal selector removed before combinator #13429 also be fixed
• the following rules are all equivalent after compiled

.foo * {
  color: red;
}

.foo {
  * {
    color: red;
  }
}

.foo {
  & * {
    color: red;
  }
}

will be compiled to

.foo *[data-v-7ba5bd90] {
  color: red;
}
.foo {
*[data-v-7ba5bd90] {
    color: red;
}
}
.foo {
& *[data-v-7ba5bd90] {
    color: red;
}
}

If #10548 still needs to fix, possible solutions include:

• Adding [id] at every level:

  • .foo .bar → .foo[data-v-xxx] .bar[data-v-xxx]
  • Downside: Performance impact due to increased selector complexity.

• Using :where(): (from @Justineo)

  • .foo .bar → .foo:where([data-v-xxx]) .bar:where([data-v-xxx])
  • Downside: Browser compatibility concerns (older browsers may not support :where).

[rkh]

IMO #10548 isn't a bug. Or rather, changing the * selector to not mean "every element" and especially changing > * to not mean "every direct child element" breaks a lot of expectations in layout systems, especially grid systems, that might be pulled in from external libraries (for instance via a SASS mixin), that the pain of dealing with it outweighs the benefits by a long shot, especially because addressing these issues is way more complex and involved than working around any problems caused by the current behavior.

If a "fix" beyond using classes or a custom id approach is still needed, maybe a counter part to :deep could be introduced?

:shallow(*) {
  color: red;
}

Either way, introducing this change in a minor release without any deprecation warning was a bit of a shock, tbh. Glad I pushed working on a fix on our side in frustration, and hadn't really begun by the time the change got reverted.

[rkh]

Not super set on it, but something like :shallow could also allow explicit control over scoping:

main :shallow(.container) :deep(a) {
  color: red;
}

[thecodewarrior]

In this case does :shallow explicitly add the scoping attribute to the selector? If that's the case :scoped might be a clearer name.

main :scoped(.container) :deep(a) {
  color: red;
}

Adding that could also allow us to selectively add scoping tags in a non-scoped CSS block, which could be helpful in some cases

[rkh]

Yes, exactly. And I do think the use case for a non-scoped context would be great.

[thecodewarrior]

Off the top of my head, there are a few things that would have to be hammered out. Most of these are somewhat obvious decisions to me but I think it's important to at least point them out.

1. How would it behave with a complex selector in it?

• For example, would :scoped(.foo .bar) translate to .foo[--] .bar[--] or .foo .bar[--]?
• I think the first result would be the expected behavior to the user, however that would mean using :scoped(.some .selector) in a non-scoped context wouldn't be equivalent to using .some .selector in a scoped context.
• Personally, I don't think that's a problem, since you could replicate the scoped context using .some :scoped(.selector) (though if we're using :where() this wouldn't have the specificity bump that the scoped context would)

2. Would it use :where() to avoid specificity issues?

• Probably best to do that, but that means :scoped(.foo .bar) would have a lower specificity than .foo .bar in a scoped context. Again I don't think that's a problem.

3. Would the scoping tag be applied to the previous selector if it's at the end?

• e.g. .foo :deep(.bar) maps to .foo[--] .bar, so would .foo :scoped(.bar) map to .foo[--] .bar[--]?
• I don't think it should, since it's really unexpected behavior.

[Justineo]

I think we should revert to always applying the attribute selector to subject selectors. While this approach has its limitations, it's more consistent and predictable.

To improve correctness, I suggest introducing a new compiler option, strictScopedStyle (open to discussion). This would allow users to opt into a new compiler output format:

.foo .bar → .foo:where([data-v-xxx]) .bar:where([data-v-xxx])

[alex-snezhko]

A point about having .foo:where([data-v-xxx]) rather than .foo[data-v-xxx] is that :where does not increase CSS specificity whereas the attribute selector does, which can result in the following scenarios if there are class name conflicts across different components depending on what order the components are built into the bundle:

• If you have a definition for .foo defined globally by a parent component, then having a scoped definition for .foo in a child would no longer override the parent (since child style is bundled before parent)
• A component with a scoped style definition for .foo could get overridden by another unrelated component with global styling for .foo if the global style component in built into the CSS bundle after the scoped style component