Following up on this morning's telcon and a previous mail [1].
Today, all browsers except Gecko simply apply the last specified rule for a given key value. The property values specified in the overridden rules have no effect on the animation.
Gecko's implementation applies the last specified rule *for each animated property* i.e. if you specify:
@keyframes example {
30% {
width: 100px;
}
30% {
color: blue;
background-color: yellow;
}
30% {
background-color: white;
}
}
...then at 30% of the timeline, Gecko applies:
30% {
width: 100px;
background-color: white;
color: blue;
}
...while all other browsers would only apply:
30% {
background-color: white;
}
In other words, Gecko's behavior is consistent with the CSS cascade. Which, among other things, makes it easy to split out an individual animated property and programmatically override it later using appendRule/deleteRule.
It also makes it a little harder to define what the current API should do e.g. what is returned when you call findRule or what happens when you call deleteRule since the 'computed' keyframe rule for a given point in the timeline may be a combination of multiple specified keyframe rules. At this point in time I will claim that the Animations OM is sufficiently broken across browsers that API compat isn't much of a concern. But since this involves a significant change to the shipping and far more compatible declarative model, the WG wants to hear from Google, Apple, Microsoft and Opera on whether or not they'd make the change, and why.
Note: I was not able to find evidence that this affects Gecko at this time. Probably because typical CSS animations do not rely on duped keyframe rules handling at this time. (some folks do modularize their animations but they use separate @keyframes for this purpose [2])
[1] http://lists.w3.org/Archives/Public/www-style/2014Mar/0497.html
[2] http://www.valhead.com/2014/03/13/screencast-getting-modular-with-css-animations/