- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Tue, 12 Apr 2011 12:53:07 -0700
- To: "L. David Baron" <dbaron@dbaron.org>
- Cc: Simon Fraser <smfr@me.com>, Dean Jackson <dino@apple.com>, www-style@w3.org
On Tue, Apr 12, 2011 at 12:32 PM, L. David Baron <dbaron@dbaron.org> wrote: > On Tuesday 2011-04-12 11:33 -0700, Simon Fraser wrote: >> On Apr 12, 2011, at 10:29 AM, L. David Baron wrote: >> > On Tuesday 2011-04-12 08:56 -0700, Tab Atkins Jr. wrote: >> >> On Mon, Apr 11, 2011 at 9:09 PM, L. David Baron <dbaron@dbaron.org> wrote: >> >>> (Alternatively, I suppose one could check for whether the property >> >>> is specified in any keyframe -- though that's a bit more work.) >> >> >> >> You need to check all the keyframes. Given a keyframe like this: >> >> >> >> @keyframes wobble { >> >> 0% { left: 0; top: 0; } >> >> 33% { top: 100px; } >> >> 67% { top: -100px; } >> >> 100% { left: 100px; top: 0; } >> >> } >> >> >> >> In the middle third of the animation, the nearest keyframe blocks >> >> don't have any mention of 'left', but 'left' is still being animated. >> > >> > The spec should perhaps mention that somewhere. >> >> Agreed :) >> >> > Additionally, it should say how that behavior interacts with timing >> > functions specified in keyframes. >> >> In this case left animates exactly as if the middle two keyframes were missing: >> >> @keyframes wobble { >> 0% { left: 0; top: 0; } >> 100% { left: 100px; top: 0; } >> } >> >> If the first keyframe had a timing-function, then that's the one that would apply. >> >> In other words, properties are interpolated between the keyframes >> that specify them. > > This makes sense -- and seems better for authors -- but it surprises > me given that (a) the spec doesn't say this and (b) the spec says > that duplicate keyframes get dropped, which is part of what led me > to the model that I interpreted (and implemented) from what the spec > does say. > > So given this model, it seems like it would make much more sense if > the spec also said that duplicate keyframes weren't dropped, but > were instead cascaded, so that, with: > > 0% { left: 0; top: 0 } > 50% { top: 40px; left: 40px } > 50% { top: 25px; } > 100% { top: 100px; left: 100px } > > you'd end up with top animating according to: > 0% { top: 0 } > 50% { top: 25px } > 100% { top: 100px } > and left animating according to: > 0% { left: 0 } > 50% { left: 40px } > 100% { left: 100px } > instead of having, as the spec currently says, left animating > according to: > 0% { left: 0 } > 100% { left: 100px } > because the second 50% keyframe overrides the first. > > > In other words, I'd propose replacing the text: > # If there are any duplicates, then the last keyframe specified > # inside the @keyframes rule will be used to provide the keyframe > # information for that time. There is no cascading within a > # @keyframes rule if multiple keyframes specify the same keyframe > # selector values. > with something that does specify cascading across different keyframe > selectors in the @keyframes rule. I also agree that cascading the keyframes would be nice, though possibly for a different reason - as currently stated, you can't animate two properties starting from the same moment with different timing functions without silly hacks like starting one at 0% and the next at 0.001%. ~TJ
Received on Tuesday, 12 April 2011 19:53:58 UTC