[scroll-animations-1] Explicit `auto` for `animation-duration` in the `animation` shorthand.

[fantasai]

As a follow up to #6530, @cdoublev filed #8570 to allow auto to be parsed in as a value for animation-duration when listed in the animation shorthand. This issue is to discuss whether we want to do that, given the complications of parsing animation.

Pros:

• Allows any value of animation-duration to be inlined into the animation property.

Cons:

• Conflicts with any other use of auto. This is unlikely to be a cause problems with keyframes names (which are unlikely to be named “auto”), but it could prevent us from easily inlining some other longhand of animation in the future.

Notes:

• It's easy to declare an auto value for animation-duration in the animation shorthand by simply omitting the duration, since it's the initial value.

Opening this issue to invite discussion about which way to go here.

[ydaniv]

@fantasai do we have a precedent of values that can't be explicitly defined? And only be declared as their default value if they're omitted?
Also, won't it be confusing if in the future we decide auto to be parsed another property?
I guess we might as well reserve auto for for duration, which seems fine for now, unless I'm missing something.

[tabatkins]

do we have a precedent of values that can't be explicitly defined? And only be declared as their default value if they're omitted?

Yes, there are a number of them. Whole properties might not be specificiable ("reset-only sub-properties"), and within properties that are specificable, there are several where longhands can express a combination that can't be written in the serialization. (My brain refuses to cough up an example, but it's the whole reason we have the "serialize as empty string" behavior for shorthands in CSSOM.)

---

For the issue at hand, I'm not too concerned with the potential "auto" conflict for animation names (seems like a very unlikely name), but I am more concerned about this being the only property that currently takes an auto keyword, and it claiming that keyword in the shorthand for the future, when it doesn't even need it (due to that being the initial value).

I'm usually against values that can only be expressed via absence, but in this case I think it's fine.

[cdoublev]

I suggested to accept auto for animation-duration in a value for animation because auto can be declared for animation-duration.

As far as I know, font is the only other shorthand serialized as empty string because its syntax intentionally does not accept some values accepted in the syntax of a sub-property (font-stretch and font-variant). I do not know the historical reasons for this.

I do not really have a problem with serializing animation omitting the initial value of animation-duration.

Furthermore, when serializing, default values of other properties must be output in at least the cases necessary to distinguish an animation-name that could be a value of another property, and may be output in additional cases.

Even if the author declared animation-name: auto; animation-duration: auto; /* ...other animation longhand declarations */, the declared value of animation-duration must not be output.

For authors, this would be the only sub-property of animation that they cannot declare explicitly.

[andruud]

+1 to @cdoublev's proposal.

I'm not too concerned with the potential "auto" conflict for animation names (seems like a very unlikely name)

It appears that auto is indeed an unlikely name. Querying HTTP Archive, I found only a single case (out of ~12.9 million) with @keyframes named auto. So the estimated risk seems low, and any problems can be trivially fixed by the author anyway.

I am more concerned about this being the only property that currently takes an auto keyword, and it claiming that keyword in the shorthand for the future

That claim can be easily satisfied by explicitly specifying auto (thus making other hypothetical auto's reachable)? I don't get why we need to introduce minor weirdness in this particular case, when "greedy claim" seems to be the default mode of any shorthand.

[bramus]

Also in favor of allowing auto in the shorthand, setting the animation-duration doing so.

[flackr]

It does seem simpler than having extra serialization complexity / oddness for the shorthand due to: the first value in each that can be parsed as a is assigned to the 'animation-duration'.

I am more concerned about this being the only property that currently takes an auto keyword, and it claiming that keyword in the shorthand for the future

Restating to make sure I understand, the problem is if we want to allow auto for some of the other longhands we wouldn't be able to make them accept auto before animation-duration in the shorthand. This wouldn't be a problem for anything that accepts times as they already are assigned in order, but could be problematic for any of the non-time properties. It would be nice to come up with some general way to handle this, e.g. animation-duration: auto becoming auto-duration or some other unique keyword.

That said, these time-accepting properties are the only current form of measurement/length in the animation property. I think there's precedent in other shorthands, e.g. background accepts auto as the background-size preventing auto from being accepted for any other background longhands.

[ydaniv]

I think we currently have 2 scenarios that require duration: auto:

1. when used with non-time-based timelines
2. potentially, when used with time-based keyframe offsets.

For case 1 omitting seems fine, since delays are ignored anyway and ranges are used instead.

For case 2, this is still being considered, but AFAICT there won't be an option to set only delay in such cases, which may become a problem.

[flackr]

duration: auto is also very useful/important as a default for group and sequence effects. This is why it's the default value if unspecified for web animations. See the definitions for the intrinsic iteration duration (the duration used when auto is specified for group effects and sequence effects. I could see delay being quite useful for these cases.

[css-meeting-bot]

The CSS Working Group just discussed [scroll-animations-1] Explicit `auto` for `animation-duration` in the `animation` shorthand., and agreed to the following:

• RESOLVED: accept "auto" as an animation-duration in the animation shorthand

The full IRC log of that discussion

<TabAtkins> flackr: scroll-driven animations, we want them to implicitly/automatically use auto duration, which matches their animation range
<TabAtkins> flackr: So this raises whether "auto" can be used in the animation shorthand.
<TabAtkins> flackr: Tab suggested this is implied by omission, but this makes it impossible to represent a non-zero delay (since duration has to exist before a delay).
<TabAtkins> flackr: So I suggest we do allow "auto" explicitly.
<TabAtkins> flackr: This is similar to other properties like background
<TabAtkins> dbaron: Are there any other things in the animation shorthand that take "auto"?
<miriam> ack dbaron
<TabAtkins> flackr: No, besides animation-name of course
<TabAtkins> fantasai: I think we discussed having delay potentially be auto
<TabAtkins> flackr: Right, no conflict because delay is already positionally unambiguous with duration
<TabAtkins> flackr: Only concern is if a non-time property takes auto
<TabAtkins> +1
<TabAtkins> proposed resolution: accept "auto" as an animation-duration in the animation shorthand
<TabAtkins> miriam: Objections?
<TabAtkins> RESOLVED: accept "auto" as an animation-duration in the animation shorthand