653999 - Unitless-zero time value causes 'animation' declaration to be ignored

Status: RESOLVED INVALID

(Core :: CSS Parsing and Computation, defect)

Description

[Eric A. Meyer]

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en; rv:1.9.0.19) Gecko/2011032020 Camino/2.0.7 (like Firefox/3.0.19)
Build Identifier: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:5.0a2) Gecko/20110501 Firefox/5.0a2

If you use a unitless zero to indicate a time interval in an 'animation' declaration, the declaration is dropped.

Example:

body {-moz-animation: spinner 36s 0 linear infinite;}
@-moz-keyframes spinner {
	0% {-moz-transform: rotate(0deg);}
	100% {-moz-transform: rotate(360deg);}
}

If you change '0' (which is indicating the animation delay) to '0s' or '0ms', the declaration is honored.

Historically, '0' has always been (optionally) unitless, since zero is zero in any and every unit scale.

For comparison, the same styles converted to -webkit- prefixes work as expected in WebKit.

Reproducible: Always

Steps to Reproduce:
1. Create a web page with the "Details" CSS applied.
2. Load the page in Aurora.


Actual Results:  
The page doesn't slowly spin.

Expected Results:  
The page should slowly spin.

Comment 1

[Robert Longson [:longsonr]]

units have only ever been optional after a 0 length, not other types http://www.w3.org/TR/css3-values/#numbers0

Comment 2

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

The rule that the unit was optional only for zero lengths, and not for zero times, angles, or frequencies goes back to CSS 2 in 1998:
http://www.w3.org/TR/1998/REC-CSS2-19980512/syndata.html#values

My memory is also that our current gradient implementation (though perhaps not the more-recent spec (?)) depends on this distinction, i.e., that parsing gradients would be ambiguous if we can't distinguish angles and lengths reliably.

Our current behavior is correct per the spec, though it'd be relatively easy to revise (modulo the gradients issue and any other parsing ambiguities that might arise) if the spec changes.

That said, another parsing issues that would arise is distinguishing animation-iteration-count from animation-duration and animation-delay in the animation shorthand.  There's already a rule that the first time is duration and the second is delay... but this gets a lot more complicated if we have to deal with things that might be a time or might be a float.  (Making sure we're ok would require that we always serialize duration and delay explicitly, always serialize iteration-count after duration and delay, and always try parsing duration and delay before trying to parse iteration-count... which would break any existing style sheets that specify an iteration-count of 0 (hopefully rare) before a duration or delay.)


So, based on the current spec, our behavior as described is correct and the bug is invalid.