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

On 11/08/2014 10:49 AM, Sylvain Galineau wrote:
>
> 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 :)

I would say that many authors don't even bother with the value 'all' and 
just have a timing value and occasionally may add a 
‘transition-timing-function’ when needed.

>>> We'd have to redefine 'all' to mean 'all properties with
>>> interpolable values' which does sound awkward.

For me, this should have been spec'ed a few years ago.

>>> 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.

What is meant by non-animatable properties? Are we talking about values 
like 'auto' or properties that do not appear in section 7.1 of CSS 
Transitions [1]. The wording in the spec should be clear if we are 
talking about non-animatable values or non-animatable properties. I 
myself am not sure what is being talked about above.

For me, 'auto' should not be be able to be animated (to or from).

One property that can be animated but do not appear in section 7.1 is 
'border-radius' and this works in Firefox, Chrome and IE11.

You can change the angle of a linear-gradient() (e.g. 30deg to 90deg) 
and it works in IE11. This even works when there is no degrees given pre 
or post transition. You can change the size and position of a 
radial-gradient() and it works in IE11.

Any thing that can be animated should be spec'ed. That is how we avoid 
breakage.


1. http://dev.w3.org/csswg/css-transitions/#animatable-css



-- 
Alan Gresley
http://css-3d.org/
http://css-class.com/

Received on Monday, 11 August 2014 15:46:57 UTC