You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[view-transitions-1] Have the -image-pair, -old, and -new pseudos inherit animation-timing-function #11546
Without the first code snippet my animations were not in sync: the default fade-in/fade-out on the new/old pseudo runs at a different curve.
I was surprised that animation-timing-function: inherit; on the pseudos isn’t part of the UA stylesheet VT styles, especially since the VT UA styles do exactly that for animation-duration + animation-fill-mode + animation-delay:
I think it would be handy to include animation-timing-function: inherit for the -image-pair, -old, and -new pseudos in the UA stylesheet so that setting a timing-function on the -group automatically gets applied on the the child pseudos as well, keeping them all in sync.
In an internal discussion it came up that we should probably inherit all animation longhand properties, save for the animation-name. Adding animation-iteration-count could work, but personally I am not too sure about animation-direction and animation-play-state.
Separately, as you mentioned, we should maybe also inherit animation-play-state. Just ran into a testing issue where we missed the fact that new/old cross faded while we were trying to have the whole thing paused
The CSS Working Group just discussed [view-transitions-1] Have the `-image-pair`, `-old`, and `-new` pseudos inherit `animation-timing-function` , and agreed to the following:
RESOLVED: Make animation-timing-function, -iteration-count, -direction, -play-state inherit in the VT tree
The full IRC log of that discussion
<TabAtkins> fantasai: We inherit some of the animation properties thru the VT tree, so you only have to specify it on -group
<TabAtkins> fantasai: so they'll all sync up their animations
<TabAtkins> fantasai: Bramus brought up that animation-timing-function should also inherit for the same reason.
<TabAtkins> fantasai: makes sense to me
<flackr> +1 sgtm
<TabAtkins> astearns: looks like Vlad wasn't sure about inheriting *everything*, but a-t-f made sense to them
<TabAtkins> fantasai: also mentioned were iteration-count and play-state. flackr probably has an idea of whether those make sense
<TabAtkins> fantasai: and direction
<TabAtkins> astearns: should we resolve on all four, or just the timing function?
<TabAtkins> flackr: maybe it makes sense to inherit all of them on VT, since they're related
<TabAtkins> flackr: i'd support all four, if we find one doesn't make sense we can revisit
<TabAtkins> PROPOSED: Make animation-timing-function, -iteration-count, -direction, -play-state inherit in the VT tree
<TabAtkins> astearns: objections?
<TabAtkins> RESOLVED: Make animation-timing-function, -iteration-count, -direction, -play-state inherit in the VT tree
Activity
bramus commentedon Mar 19, 2025
In an internal discussion it came up that we should probably inherit all
animationlonghand properties, save for theanimation-name. Addinganimation-iteration-countcould work, but personally I am not too sure aboutanimation-directionandanimation-play-state.vmpstr commentedon Mar 20, 2025
I'd prefer we deal with them on a case-by-case basis.
animation-timing-functionmakes sense though.vmpstr commentedon Mar 27, 2025
Separately, as you mentioned, we should maybe also inherit
animation-play-state. Just ran into a testing issue where we missed the fact that new/old cross faded while we were trying to have the whole thing pausedcss-meeting-bot commentedon Jun 25, 2025
The CSS Working Group just discussed
[view-transitions-1] Have the `-image-pair`, `-old`, and `-new` pseudos inherit `animation-timing-function`, and agreed to the following:RESOLVED: Make animation-timing-function, -iteration-count, -direction, -play-state inherit in the VT treeThe full IRC log of that discussion
<TabAtkins> fantasai: We inherit some of the animation properties thru the VT tree, so you only have to specify it on -group<TabAtkins> fantasai: so they'll all sync up their animations
<TabAtkins> fantasai: Bramus brought up that animation-timing-function should also inherit for the same reason.
<TabAtkins> fantasai: makes sense to me
<flackr> +1 sgtm
<TabAtkins> astearns: looks like Vlad wasn't sure about inheriting *everything*, but a-t-f made sense to them
<TabAtkins> fantasai: also mentioned were iteration-count and play-state. flackr probably has an idea of whether those make sense
<TabAtkins> fantasai: and direction
<TabAtkins> astearns: should we resolve on all four, or just the timing function?
<TabAtkins> flackr: maybe it makes sense to inherit all of them on VT, since they're related
<TabAtkins> flackr: i'd support all four, if we find one doesn't make sense we can revisit
<TabAtkins> PROPOSED: Make animation-timing-function, -iteration-count, -direction, -play-state inherit in the VT tree
<TabAtkins> astearns: objections?
<TabAtkins> RESOLVED: Make animation-timing-function, -iteration-count, -direction, -play-state inherit in the VT tree
VT: Inherit more animation properties across the pseudo subtree
VT: Inherit more animation properties across the pseudo subtree
VT: Inherit more animation properties across the pseudo subtree
[view-transitions] Inherit more animation properties in the pseudo-el…
[css-view-transitions-1] Inherit more animation properties in the pse…
Bug 1977911 [wpt PR 53815] - VT: Inherit more animation properties ac…
VT: Inherit more animation properties across the pseudo subtree