- From: Noam Rosenthal via GitHub <sysbot+gh@w3.org>
- Date: Mon, 19 Aug 2024 15:03:41 +0000
- To: public-css-archive@w3.org
noamr has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-view-transitions-2] Retaining `view-transition-class` (and `view-transition-group`) from old state == When resolving `view-transition-class`, the rule is "last capture wins". That means that as long a view-transition has a new state, the old class is discarded. However, there are legit use-cases for retaining the "old" class without having to explicitly specifying it again. For example, if the author uses an ordinary class `in-viewport` to ascertain that a certain element intersects with the viewport, they should be able to use the following to customize the animation: ```css .element.in-viewport { view-transition-class: fly; } .element:not(.in-viewport) { view-transition-class: fade; } ``` With the current "last capture wins" rule, the `fade-only` rule would only apply when the element flys *out*, and it's impossible to use `view-transition-class` to make it fade also when flying in, because `.in-viewport` would be true in the new state. Proposing to have a function that applies to `view-transition-class`, and can be applied to `view-transition-group` if we use the same rule in #10631, that copies the value from the old state. e.g.: ```css view-transition-class: from-old() new-class-1 new-class2; ``` There is probably a better name for this, but the general idea is that a particular function "copies over" the names from the old state, and that this is specific to view-transitions rather than a generic merge primitive. /cc @khushalsagar @vmpstr @nt1m @fantasai Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10757 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 19 August 2024 15:03:42 UTC