[csswg-drafts] [css-view-transitions] Normalize the exposed `transform` for `::view-transition-group()` pseudos to be Viewport-relative. (#11456)

bramus has just created a new issue for https://github.com/w3c/csswg-drafts:

== [css-view-transitions] Normalize the exposed `transform` for `::view-transition-group()` pseudos to be Viewport-relative. ==
When [setting up a View Transition](https://drafts.csswg.org/css-view-transitions-1/#setup-view-transition-algorithm), all `transform`s are relative to the [snapshot containing block origin](https://drafts.csswg.org/css-view-transitions-1/#snapshot-containing-block-origin).

Relevant spec snippets:

> Set capture’s [old transform](https://drafts.csswg.org/css-view-transitions-1/#captured-element-old-transform) to a [<transform-function>](https://drafts.csswg.org/css-transforms-2/#typedef-transform-function) that would map element’s [border box](https://drafts.csswg.org/css-box-4/#border-box) from the [snapshot containing block origin](https://drafts.csswg.org/css-view-transitions-1/#snapshot-containing-block-origin) to its current visual position.

> Set transform to a transform that would map newRect from the [snapshot containing block origin](https://drafts.csswg.org/css-view-transitions-1/#snapshot-containing-block-origin) to its current visual position.

These transforms are then used in the `::view-transition-group`’s keyframes _(setting the starting position)_ and on the element itself _(setting its ending position)_.

For example, when animating a `position: fixed` element in a browser that has a retractable top bar of `56px` high, a `top,left` translation from `100,100` to `24,24` of that element results in the following transforms:

- from `transform`: `matrix(1, 0, 0, 1, 100, 156)`
- to `transform`: `matrix(1, 0, 0, 1, 24, 80)`

See this screenshot taken in Chrome on Android: the box got animated from position `24,24` as measured against the viewport (red outline + red arrow) but ends up being `24,80` when measured against the snapshot containing block (blue outline + blue arrow)

![vt-snapshot-containing-block](https://github.com/user-attachments/assets/4e2de588-0746-420a-95d2-740c0fa316f3)

---

When [getting the keyframes](https://www.bram.us/2025/01/01/view-transitions-snippets-getting-all-animations-linked-to-a-view-transition/) of the resulting `::view-transition-group` pseudo using `animation.effect.getKeyframes()` you end up with the following (simplified):

```js
[
  {
    computedOffset: 0,
    transform: "matrix(1, 0, 0, 1, 100, 156)"
  },
  {
    computedOffset: 1,
    transform: "matrix(1, 0, 0, 1, 24, 80)"
  }
]
```

From an author POV these values are problematic, because the `transform`s contain values that are not relative to the coordinate space authors have access to, namely the (layout) viewport:

- Extracting the start and end positions from these keyframes yields values that are off by `<height-of-the-retractable-top-bar>`
- Doing something like `animation.effect.setKeyframes(animation.effect.getKeyframes())` is destructive because the element has now shifted by `<height-of-the-retractable-top-bar>`.

To fix this issue I suggest that engines keep on using the snapshot containing block-relative offsets internally, but expose viewport-relative offsets to authors.

That way authors can rely on the keyframes for extracting the correct positional information and manipulate the generated keyframes without needing to worry about messing up the positions.

Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/11456 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Tuesday, 7 January 2025 21:58:44 UTC