Repository navigation
[css-animations-2] Should the initial value for animation-duration be auto? #6530
Description
css-animations-1 defines the initial value of animation-duration to be 0s. However, the web-animations specification allows for the 'auto' keyword which is useful for scroll-animations and group animations where the duration should be determined automatically.
Since the computed value of 'auto' for regular animations is 0s, it seems to me that we could safely change the initial value of animation-duration to be 'auto', and this would allow using a scroll-timeline animation or possibly a group effect animation without having to explicitly set the auto duration.
@birtles WDYT?
Activity
flackr commentedon Aug 20, 2021
The one place I can think of where this would be web visible today is the getTiming() method if you were to call getAnimations() on a fill: forward css animation. e.g. https://jsbin.com/kawubir/edit?css,js,output
birtles commentedon Aug 20, 2021
If I understand correctly, this is about introducing an
autokeyword to the CSS syntax foranimation-durationand mapping that to an'auto'value in Web Animations. I think that sounds reasonable but, like you mentioned, there is some Web compat risk.flackr commentedon Nov 9, 2022
@andruud noted this would also be exposed in
getComputedStylesince we wouldn't have determined it to be 0 yet. This raises the risk of having it be the initial value as usage ofgetComputedStyleis much higher. Typically, developers would usually be reading the duration of elements animations which have durations, but if they didlet duration = parseFloat(getComputedStyle(elem).duration)this would result in NaN for"auto"instead of 0 from"0s":(.Proposals:
We should definitely support specifying the
autovalue in css-animations for animation-duration.I also think ergonomically it would be a much better initial value:
autoor a time value and rely on the conversion from a time based animation to a progress based one is an awkward requirement, e.g.animation: keyframes scroll()should "just work".If we decide that we have to keep
0sas the initial value we could update the conversion from a time based animation to a progress based one to effectively convert0sanimations to 100% as well, but this feels a bit more surprising especially if combined with proportion based delays.@fantasai FYI
css-meeting-bot commentedon Dec 8, 2022
The CSS Working Group just discussed
[css-animations-2] Should the initial value for animation-duration be auto?, and agreed to the following:RESOLVED: Add auto as default valueThe full IRC log of that discussion
<Rossen_> https://github.com//issues/6530#issuecomment-1308954151<dael> flackr: css animations spec the initial value to be 0sec but times don't make sense for scroll linked animations. In web default was auto
<dael> flackr: First is we should support auto in css animations because that's what we use to map to a range of scroll or view timeline
<bramus> +1
<heycam> q+
<dael> birtles: For background I think we added auto to web animations because we anticipated group effects where duration stretches to fill the group
<dael> heycam: What is the effect of specifying animation duration of some other value
<Rossen_> ack heycam
<dael> flackr: Currently have spec that if all durations are time based we convert to relative proportions of animation. This doesn't work for 0
<dael> flackr: And this is in web animations 2 spec
<dael> flackr: Not sure if we want to keep that or remove, but hope is most devs use auto which we convert to timeline specific
<dael> heycam: Yeah was just wondering if it's sensible to use specific time values. It's something authors will want to do and in that case is 0 sec useful. Sounds like no for 0
<ydaniv> q+
<dael> flackr: Right, 0 is not really something that should produce and effect
<dael> s/and/an
<Rossen_> ack ydaniv
<dael> ydaniv: Did you also consider allowing length and duration?
<dael> flackr: There is a separate issue filed for this.
<dael> ydaniv: but it's not colliding?
<dael> ydaniv: There's no collision between using auto as the initial
<dael> flackr: No, there should be no issue with using initial if we do length. Computed value of auto is 0 if they're not part of a group so we would just be saying computed value is whatever makes sense for a scroll linked animation
<dael> flackr: Proposal is that's 100%
<Rossen_> q?
<dael> Rossen_: Other opinions
<dael> flackr: Two proposals, one is add auto. auto as initial is separate proposal
<bramus> q+
<dael> flackr: I would like both
<Rossen_> ack bramus
<dael> bramus: I would like auto to be the default b/c if you set an animation timeline you need to change animation duration to 1sec or non-0 for animation timeline to work which is weird for author. for auto you don't need that
<dael> flackr: That's exactly why I want auto as initial
<dael> Rossen_: Prop: Add auto as default value
<dael> Rossen_: Obj?
<dael> RESOLVED: Add auto as default value
[css-animations-2] Add 'auto' as initial value of 'animation-duration'.
fantasai commentedon Mar 11, 2023
@flackr Edits in 2a7cc4b ; the main question I have (which isn't clear from the minutes) is whether some of these value conversions should be at computed-value time, resolved-value time, or used-value time. Currently they're specced as used-value, but if we want getComputedStyle() to return something backwards-compatible, it would need to be resolved value.
flackr commentedon Mar 27, 2023
When we resolved we were assuming that it would be backwards incompatible if developers were reading and using the value from the computed style. Since the
autois passed as is as to the duration in the underlying animation, see https://drafts.csswg.org/web-animations-1/#dom-effecttiming-duration, I think it makes sense for getComputedStyle to return auto.cdoublev commentedon Mar 28, 2023
13 remaining items
andruud commentedon Jun 12, 2023
A given animation-duration can be associated with multiple animation-timelines due to repeats:
What is the resolved value of animation-duration in that case?
flackr commentedon Jun 12, 2023
I believe
animation-durationand other animation properties are auto repeated to match up with the number of defined animation names per https://www.w3.org/TR/css-animations-1/#animation-name so I'd expect the computed style would beanimation-duration: auto, 0s;andruud commentedon Jun 12, 2023
Hmm, exposing that repeat would be another (separate) breaking change. Perhaps we should only trigger the legacy 0s-ification when
animation-timelineis exactlyauto, i.e. when all the animations must be time-based.flackr commentedon Jun 12, 2023
Yeah, I think that would be fine. If you've got auto values mixed in it's not going to support parsing as a number anyways.
fantasai commentedon Jun 12, 2023
Agenda+ to confirm @andruud's tweak in #6530 (comment)
See also PR #8952
[css-animations-2] Make animation-duration:auto resolve to 0s for leg…
[css-animations-2] Make animation-duration:auto resolve to 0s for leg…
gkalpak commentedon Jun 19, 2023
I see that the latest decision is to retain backwards compatibility for
getComputedStyle().animationDuration(returning0sinstead ofauto), which is great 🎉I just wanted to mention (mostly for people that might run into this on some beta versions of Chrome/Edge) that the original proposal of having
getComputedStyle()returnautoforanimation-durationbreaks CSS-based animations in the AngularJS (v1.x) framework.I think this might also be useful as a data-point for future backwards compatibility considerations.
Although the AngularJS v1.x series is end-of-life, there are many (mainly enterprise) apps still running on one of the old unmaintained versions or using a patched version from a Long-Term Support provider, such as XLTS.dev.
css-meeting-bot commentedon Jun 28, 2023
The CSS Working Group just discussed
[css-animations-2] Should the initial value for animation-duration be auto?, and agreed to the following:RESOLVED: Go with option 2, "check for only the initial value (one list item, being auto)"The full IRC log of that discussion
<drott> fantasai: We changed animation-duration initial value to auto<drott> fantasai: But we need that to return 0 seconds for time based animations
<drott> fantasai: someone? wanted to clarify when that triggers
<fantasai> https://github.com//pull/8952
<drott> fanatasai: drafted a PR for that (triggers when animation timeline is at 0(
<drott> fantasai: if there is only one list value, and that computed value is auto
<Rossen_> q?
<flackr> q+
<drott> fantasai: wanted to confirm with the working group - is the draft suitable? Which version do we want to go with?
<Rossen_> ack flackr
<fantasai> fantasai: alternative is to allow multiple values, but all of them need to be auto
<drott> flackr: the significant use case is: initial value of animation timeline should be covered
<drott> flackr: proposed PR is good in that regard, unless developer changes animation timeline
<drott> flackr: reason we didn't want to expose multiple values was: didn't want to expose the duration (?)
<flackr> s/?/duration repeat behavior
<drott> rossen_: any reasons for concern?
<drott> rossen_: proposal to stick with single value?
<fantasai> Options were:
<fantasai> 1. auto values individually convert to 0s, can have a mixed list
<fantasai> 2. check for only the initial value (one list item, being auto)
<fantasai> 3. check for the entire list being auto (but multiple values ok)
<drott> rossen_: no objections heard to go with single value?
<drott> rossen_: based on that clarification, anyone changed their mind?
<drott> RESOLVED: Go with option 2, "check for only the initial value (one list item, being auto)"
[css-animations-2] Make animation-duration:auto resolve to 0s for leg…
graouts commentedon Jan 30, 2026
Should the test associated with this issue,
scroll-animations/css/animation-duration-auto.tentative.html, be marked as non-tentative now? WPT.fyi indicates that Firefox and Safari both pass 5/5, but Chrome and Edge are 4/5.