[Tab Atkins Jr.:] > The reason I call it hacky is not its lack of discoverability (though > that's a problem), but because it relies on the author guessing at an > appropriate epsilon to add to the keyframe time. If they guess too large, > it might be detectable in some cases as a small lag before the property > starts animating again. If they guess too small, they'll run into impl > precision limits and might accidentally collapse it into the same time, > which has a bad effect. (That is, "50%" and "50.000001%" > might be the same time, depending on impl limits.) > > We generally try to avoid doing things like this, where rounding behavior > is potentially exposed to authors. > Yes, we would still want a keyword that indicates the next keyframe rule defines, well, the next frame in the animation. Somehow allowing multiple keyframe rules with the same selector would not be backward-compatible and I think it should really be an explicit selector value or function. May not make this level but I'll add it to the bug list.Received on Tuesday, 20 November 2012 21:57:01 GMT
This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:21:02 GMT