[csswg-drafts] [css-view-transitions-2] Reflecting `view-transition-group` in computed style (#10638)

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

== [css-view-transitions-2] Reflecting `view-transition-group` in computed style ==
Folllow up on #10334

We defined a few rules on how `view-transition-group` is computed:
- A few keywords (`nearest`/`normal`/`contain`)
- Some rules that define whether a group is valid (e.g. has to refer to an ancestor `view-transition-name`)

We have all the information we need during style computation to compute a resolved `view-transition-group`, so hypothetically
`getComputedStyle` can already return the resolved group. It fits with other things that `getComputedStyle` does (colors, length, transforms etc). The other option is to resolve them when capturing

There are a few options:
1. Style computation just passes things along to the view transition engine, reflecting the keywords and everything to `getComputedStyle`
2. Style computation resolves the `nearest`/`normal`/`contain` keywords, but doesn't resolve rules that depend on the existence of `view-transition-name`.
3. Style computation resolves everything and `view-transition-group` is always computed to be a valid ancestor `view-transition-name`.

I think (3) would be the most useful for developers and consistent with other things `getComputedStyle` does, but perhaps the overhead on style computation is unnecessary.

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


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

Received on Monday, 29 July 2024 16:37:24 UTC