Clarify nature of `transform` in `-group` pseudo elements

[mattgperry]

The docs state, on ::view-transition-group(*)

Also the element’s transform is animated from the old element’s screen space transform to the new element’s screen space transform.

When inspecting the generated element's CSSAnimation, these keyframes return as matrix(...identity, oldScreenX, oldScreenY) and none. Replacing this animation with a WAAPI animation with the same keyframes produces the expected animation of the layer animating from oldScreenX/Y to 0,0, the top left of the screen (none).

Is there then something additional at play that isn't mentioned in the spec? I would expect none to be an explicit value like the first keyframe, or for it to behave correctly when replacing the animation with the equivalent WAAPI animation.

Edit:

This code is enough to break the animation

effect.setKeyframes(effect.getKeyframes())

[mattgperry]

Expected:
https://github.com/user-attachments/assets/3a871968-4134-4f19-b906-acee831388f5

Broken:
https://github.com/user-attachments/assets/cbd02931-7192-4cd7-933f-25461857171e

[bramus]

I believe there are bugs in both Chrome and Safari related to this:

• Chrome/Blink: uses "none" in the to keyframe. While that is technically allowed (because the pseudo itself has a transform declared on it and the spec says to only generate the from keyframe), re-setting that seems to trip things up like you mentioned. Bug report: https://issues.chromium.org/issues/387030974.
• Safari/WebKit uses the same transform value in the to keyframe and from keyframes. The to value is wrong. Bug report: https://bugs.webkit.org/show_bug.cgi?id=285277

Personally, I would love to see if the keyframes included both the to and from transform values (i.e. bot have transform set to matrix(1, 0, 0, 1, …)), instead of relying on the pseudo’s transform value. This would allow authors to extract the to/from positions from the effects themselves instead of needing to get those values using a getBoundingClientRect().

[bramus]

Checking the relevant section of the spec I see the created keyframes are spec-compliant: only generate the from keyframe.

Digging deeper into getKeyframes I believe it’s the “compute missing keyframe offsets” that is causing the extra keyframe to be inserted.

This makes me believe that there are issues in both Chrome and Safari related to this last part:

• Chrome/Blink fills the missing keyframe’s values with initial values which is technically correct (I guess?) but becomes problematic when reapplying them with effect.setKeyframes(effect.getKeyframes()).
• Safari/WebKit mixes things up uses the values from the to keyframe in the from keyframe.

See https://codepen.io/bramus/pen/ogvobYQ?editors=0010 for a demo.

I’ll file a CSSWG issue about this, as this is about a feature that already shipped in browsers (this repo is more for incubating new VT-features)

[bramus]

I dug deeper into this and boiled it down to purely bugs in Blink and WebKit related to calling getKeyframes() on effects set on ::view-transition-group() pseudos. For regular animations the result of calling getKeyframes() produces two complete frames with correct values: see demo.

I believe this issue may be closed.

[bramus]

I gave this some more thought and think I would want the exposed coordinates to be viewport-relative so that things like animation.effect.setKeyframes(animation.effect.getKeyframes()) is not destructive.

I have filed w3c/csswg-drafts#11456 with the CSS Working Group for this.