[css-view-transitions-2] @view-transition resolution algorithm should cascade

[bokand]

The @view-transition resolution algorithm is currently specifies:

To get the resolve @view-transition rule for a Document document:

1. Let matchingRule be the last @view-transition rule in document which has a navigation descriptor whose computed value is auto.
2. If matchingRule is not found, then return "not found".
3. Return a list of strings corresponding to that descriptor’s computed value.

But I think it needs to account for the CSS cascade. Take this example:

<style>
  @view-transition {
    navigation: auto;
    type: foo;
  }

  @import url('style.css') layer(A);
</style>

  /*style.css*/
  @view-transition {
    navigation: auto;
    type: bar;
  }

I would expect the foo transition to be resolved, despite the fact that the bar transition is "last".

I think the way to do this will be to keep a map of all encountered @view-transition rules, keyed by their matcher descriptors (currently just navigation but later including from, to, etc. with succeeding levels of the cascade overriding a entries where the matchers are equal.

---

While we're here:

Return a list of strings corresponding to that descriptor’s computed value.

I'm assuming "that descriptor" is navigation?

[bokand]

cc @noamr

[bokand]

I'm assuming "that descriptor" is navigation?

err, reading how the value is used it seems to be looking for the value of the type descriptor

[noamr]

OK so cascade in the layer sense. +1 for this. AFAIC we can get.a WG resolution or simply add it to the spec.

[bokand]

This seems to just be standard behavior for CSS rules and I saw in the notes lots of agreement that it should work like @font-face - I've confirmed @font-face does cascade in this way: https://viewtransition.glitch.me/fontface.html

So I think we're probably good to just add it to the spec?

[khushalsagar]

+1 to @bokand's comment. That was the intent of the resolution so we can just update the spec.

[noamr]

Apparently there is no spec language to say that a rule/descriptor cascades in this way... this is implicit in the cascading soec. So I'm not sure if this issue is actionable. The implied behavior should be as described: the last rule is selected after cascading is applied.

[fantasai]

This is defined in Cascade 5 here:

Name-defining at-rules such as @keyframes or @font-face that are defined inside cascade layers also use the layer order when resolving name collisions.

Probably the wording needs to be tweaked a bit to account for @view-transition and @page, which don't technically define names. :)

[noamr]

This is defined in Cascade 5 here:

Name-defining at-rules such as @keyframes or @font-face that are defined inside cascade layers also use the layer order when resolving name collisions.

Probably the wording needs to be tweaked a bit to account for @view-transition and @page, which don't technically define names. :)

Thanks for the pointer, on it!