[css-animations] Negative time at start of animation shorthand

[ewilligers]

https://drafts.csswg.org/css-animations/#animation

"the first value in each <single-animation> that can be parsed as a <time> is assigned to the animation-duration, and the second value in each <single-animation> that can be parsed as a <time> is assigned to animation-delay."

Negative <time> values are invalid for animation-duration.

Does this mean that if a negative <time> (like '-5s') appears at the start of animation, the shorthand value is invalid?

Spec (possible reading):
The negative value is rejected as it is only considered for animation-duration.
Reading the specified animation gives ''.
Reading computed animation gives values from style rules, or initial values.

Edge 18:
The negative value is accepted as animation-duration.
Reading the specified animation gives '-5s'.
Reading computed animation gives ''.

Safari:
The negative value is accepted as animation-delay.
Reading the specified animation gives '-5s'.
Reading computed animation gives ''.

Firefox:
The negative value is accepted as animation-delay.
Reading the specified animation gives '0s ease -5s 1 normal none running none'.
Reading computed animation gives ''.

Blink:
The negative value is accepted as animation-delay.
Reading the specified animation gives '0s ease -5s 1 normal none running none'.
Reading computed animation gives '0s ease -5s 1 normal none running none'.

https://jsfiddle.net/ericwilligers/eapsLyub/

[ewilligers]

This also affects transition.

the first value that can be parsed as a time is assigned to the transition-duration, and the second value that can be parsed as a time is assigned to transition-delay.

Negative <time> values are invalid for transition-duration.

Suppose the author specifies transition as '-5s'.

Spec (possible reading):
The negative value is rejected as it is only considered for transition-duration.
Reading the specified transition gives ''.
Reading computed transition gives values from style rules, or initial values.

Edge 18:
The negative value is accepted as transition-duration.
Reading the specified transition gives '-5s'.
Reading computed transition gives ''.

Safari:
The negative value is accepted as transition-delay.
Reading the specified transition gives '-5s'.
Reading computed transition gives 'all 0s ease -5s'.

Firefox:
The negative value is accepted as transition-delay.
Reading the specified transition gives 'all 0s ease -5s'.
Reading computed transition gives ''.

Blink:
The negative value is accepted as transition-delay.
Reading the specified transition gives 'all 0s ease -5s'.
Reading computed transition gives 'all 0s ease -5s'.

https://jsfiddle.net/ericwilligers/ho3jxw4r/

[birtles]

Firefox:
The negative value is accepted as transition-delay.
Reading the specified transition gives 'all 0s ease -5s'.
Reading computed transition gives ''.

Blink:
The negative value is accepted as transition-delay.
Reading the specified transition gives 'all 0s ease -5s'.
Reading computed transition gives 'all 0s ease -5s'.

I think the discrepancy there is just due to Firefox not returning shorthands from getComputedStyle right? (Bug 137688). i.e. for the purpose of this issue, I believe Gecko and Blink agree.

[ewilligers]

for the purpose of this issue, I believe Gecko and Blink agree.

For the purpose of this issue, I believe Gecko and Blink and Safari agree: they all accept the leading negative time as animation-delay / transition-delay.

[ewilligers]

We could have

Note that order is important within each animation definition: the first value in each single-animation that can be parsed as an animation-duration is assigned to animation-duration, and if a single-animation contains another value that can be parsed as a time, it is assigned to animation-delay.

This allows for cases like
calc((20px - 1em) / 1px * 1s) linear calc((1em - 20px) / 1px * 1s) anim
where, regardless of font-size, the first time value is animation-duration.