1914188 - @scope support for invalidation

Status: NEW

(Core :: CSS Parsing and Computation, enhancement)

Description

[David Shin[:dshin]]

Currently, the any @scope-utilizing styles do not invalidate on id/class/state/DOM mutations/etc correctly.

Comment 2

[David Shin[:dshin]]

Attachment: Mixed implicit/explicit nested scoping that should invalidate every second

This looks Fun..
EDIT: I think in this particular case we could ignore the implicit selector (At the cost of over-invalidation), but if the innermost @scope is implicit, and the style rule inside it is :scope, we're going to need some way to map that out.

Comment 3

[David Shin[:dshin]]

Some notes for implementation:

1. Add Dependency based on scope selectors. For:

@scope (.a .b .scope-1-start) to (.c. .d .scope-1-end) {
  @scope (.e .f .scope-2-start) to (.g .h .scope-2-end) {
    .i .j .foo {}
  }
}

We need a dependency structure that looks equivalent to: :is(:is(.a .b .scope-1-start):not(.c. .d .scope-1-end) .e .f .scope-2-start):not(.g .h .scope-2-end) .i .j .foo

Which means:

1. Dependency for .a .b .scope-1-start whose parent dependency points to .e .f .scope-2-start
2. Dependency for .c. .d .scope-1-end whose parent dependency points to .e .f .scope-2-start
3. Dependency for .e .f .scope-2-start whose parent dependency points to .i .j .foo
4. Dependency for .g .h .scope-2-end whose parent dependency points to .i .j .foo
5. Dependency for .i .j .foo (Already generated)

We'll probably want to cache this computation so we don't make these dependencies over and over again.

2. We need to handle there being implicit scoping somewhere in the nesting, like in Bug 1914188 comment 2. Fortunately, because you can't reference other implicit scopes, this should happen only once in the nesting chain. i.e. You can't somehow have @scope <implicit-outer> @scope <implicit-inner>, and @scope { @scope{} } will never match anything, and declarations like

<div>
  <style>@scope {}</style>
  <div>
    <style>@scope {}</style>
  </div>
</div>

Carry no nesting relationship for the purpose of invalidation.

We need a special type of invalidation here, though. Fortunately, it travels downwards, so it can be handled by normal validation, unlike :has(). However, when the invalidator hits the implicit scope as a parent dependency, the invalidator needs to traverse all descendants, and for all that are implicit scope roots, run the parent dependency invalidation for each.

3. Collect invalidation shortcuts for scoped selectors. Need something to make sure we aren't adding many times over and over again.

4. Need to fill selectors for cache revalidation.

Comment 4

[David Shin[:dshin]]

Some musings about :has() in @scope, and its impact on invalidation:

1. Under "normal" scenarios, where :has() is used only once in the @scope stack, above should work just fine.
2. Referencing :scope in :has() in any context will result in that scope never activating/deactivating (If used in scope end selector), since nested scopes imply that the inner scope root is a descendant of the outer scope root, but :has() implies an incompatible relationship (outer root is descendant/child of inner root, or outer root is later/next sibling of inner root). So we don't have to worry about a normal invalidation suddenly becoming a relative invalidation (e.g. With @scope (.foo) { @scope (:has(:scope .bar)) {}}, and toggling .foo, we can just ignore the inner scope altogether).

Comment 5

[709922234]

any update?

Comment 6

[709922234]

Animation is not currently supported

e.g: https://duoyun-ui.gemjs.org/en/elements/segmented

Comment 7

[David Shin[:dshin]]

(In reply to 709922234 from comment #6)

Animation is not currently supported

e.g: https://duoyun-ui.gemjs.org/en/elements/segmented

If I understand this correctly, we're talking about .marker's inset transitions, right? That looks to be anchor-positioning related - See bug 1924226.