W3C home > Mailing lists > Public > www-style@w3.org > August 2014

Re: [css-animations] When/how are keyframe values computed?

From: Sylvain Galineau <galineau@adobe.com>
Date: Mon, 11 Aug 2014 00:49:56 +0000
To: Lea Verou <lea@verou.me>
CC: "L. David Baron" <dbaron@dbaron.org>, Tab Atkins Jr. <jackalmage@gmail.com>, "<www-style@w3.org>" <www-style@w3.org>
Message-ID: <EAC91CF8-8155-427C-AF05-229DDD632BFF@adobe.com>

On Aug 10, 2014, at 5:17 PM, Lea Verou <lea@verou.me> wrote:

> On Aug 11, 2014, at 03:08, Sylvain Galineau <galineau@adobe.com> wrote:
>> Yes, if it is common to not define transition-property and rely on its initial value of 'all' then this could cause some awkward surprises.
> Itís *extremely* common. Iíd say itís the most common way transitions are used.
I believe it. After all, not maintaining a list of properties sounds like less work :)

>> We'd have to redefine 'all' to mean 'all properties with interpolable values' which does sound awkward.
>> At the same time, if animating all values is a good thing for animations it also seems awkward to arbitrarily prevent it in transitions. Or maybe animations are the fallback in this case?
> IMO it would be very useful to allow this in transitions as well and would open up some very interesting possibilities that require hacks today.
> One solution that minimizes (but doesnít completely eliminate) the backwards compat consequences would be to make `all` mean all properties, but redefine the initial value to a new keyword that means "all interpolatable properties". Since most authors use `all` implicitly, that would prevent most cases of breakage. 

Speaking of which, it's not 100% clear to me what is supposed to happen to non-animatable properties. Do they transition immediately as they do in a browser with no css-transitions support? Or should they switch at the end of the specified duration? Either way, it still seems awkward for these properties to change value at a different point than in css-animations. 

I might have missed the css-transitions prose for this though.
Received on Monday, 11 August 2014 00:50:27 UTC

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