W3C home > Mailing lists > Public > www-style@w3.org > December 2009

Re: [css3-animations] What if different keyframes have different sets of properties?

From: L. David Baron <dbaron@dbaron.org>
Date: Tue, 22 Dec 2009 16:32:59 -0500
To: Brad Kemper <brad.kemper@gmail.com>
Cc: Simon Fraser <smfr@me.com>, "www-style@w3.org" <www-style@w3.org>
Message-ID: <20091222213259.GB1491@pickering.dbaron.org>
On Tuesday 2009-12-22 12:01 -0800, Brad Kemper wrote:
> On Dec 22, 2009, at 11:00 AM, Simon Fraser <smfr@me.com> wrote:
> >We see value in using the unanimated value of the property to replace
> >missing values, because it allows the author to use keyframes to animate
> >something to and from where it is now. I think this is more useful than using
> >'forward fill' logic.
> 
> That seems good for the beginning keyframe(s) and the ending
> keyframe(s ). But I'm more ambivalent about it's appropriateness for
> when there is a missing declaration between two frames that do have
> a value for that property, like this one:
> 
> # @keyframes one {
> #   from { top: 100px; left: 100px; }
> #   50%  { top: 200px; }
> #   to   { top: 100px; left: 300px; }
> # }
> 
> Is that still useful to refer to the unanimated value in the middle
> of the animation, or is it just unexpected and missing out on a way
> to write shorter, cleaner code (where you only have to write the in-
> between values of the proprties that you want different from what
> would be automatically in-betweened)?

I actually rather like the way Simon described it; it makes it much
clearer to me how animations is an extension of transitions (which I
didn't previously understand).  My understanding is now that
animations simply applies the various rules inside the @keyframes
rule at the relevant stages of the animation (overriding all other
rules), and then transitions between them.

-David

-- 
L. David Baron                                 http://dbaron.org/
Mozilla Corporation                       http://www.mozilla.com/
Received on Tuesday, 22 December 2009 21:33:30 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 22 May 2012 03:47:12 GMT