- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Tue, 20 Nov 2012 12:51:09 -0800
- To: Sylvain Galineau <sylvaing@microsoft.com>
- Cc: www-style list <www-style@w3.org>
On Tue, Nov 20, 2012 at 12:09 PM, Sylvain Galineau <sylvaing@microsoft.com> wrote: > [Tab Atkins Jr.:] >> You can hack around the issue a bit by using >> "animation-timing-function: step-start;" in the first keyframe, so it at >> least flips immediately to the next value without a transition in the >> middle, but this is hacky and non-obvious. > > Hard to judge what is non-obvious but setting some value of animation-timing-function > on the keyframe in question seems the right approach to me. We allow animation-timing-function > to be specified on individual keyframes so the author can control how values transition during > a keyframe. Overall I do not think the step-start answer would non-obvious to someone who > understands the step-* values. I think it is true, however, that many people do not know you > can set animation-timing-function within @keyframes. > > So while we can argue on how discoverable this may be I do not think it is 'hacky'. 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. ~TJ
Received on Tuesday, 20 November 2012 20:51:56 UTC