[css-animations-2] Should the initial value for animation-duration be auto?

[flackr]

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?

[flackr]

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]

If I understand correctly, this is about introducing an auto keyword to the CSS syntax for animation-duration and 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]

@andruud noted this would also be exposed in getComputedStyle since we wouldn't have determined it to be 0 yet. This raises the risk of having it be the initial value as usage of getComputedStyle is much higher. Typically, developers would usually be reading the duration of elements animations which have durations, but if they did let duration = parseFloat(getComputedStyle(elem).duration) this would result in NaN for "auto" instead of 0 from "0s" :(.

Proposals:

1. We should definitely support specifying the auto value in css-animations for animation-duration.

2. I also think ergonomically it would be a much better initial value:

   • Time-based durations don't make sense for scroll linked animations and having to specify auto or 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".
   • It results in the same duration for time-based animations.

   If we decide that we have to keep 0s as the initial value we could update the conversion from a time based animation to a progress based one to effectively convert 0s animations to 100% as well, but this feels a bit more surprising especially if combined with proportion based delays.

@fantasai FYI

[css-meeting-bot]

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 value

The 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

[fantasai]

@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]

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 auto is 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.