W3C home > Mailing lists > Public > www-style@w3.org > November 2012

Re: [css3-animations] Ability to have "adjacent" keyframes / "instantaneous" interpolations

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Tue, 20 Nov 2012 12:51:09 -0800
Message-ID: <CAAWBYDBQHH_zqXqbnpoZFN3W8qHV84KPUQP3L+cSinMKTSBTAw@mail.gmail.com>
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.

Received on Tuesday, 20 November 2012 20:51:56 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:23 UTC