Re: [css3-animations] animate display, other non-animatable properties

What if I want to continue to use 'linear' when it's supported (colors, 
lenght...) and discrete otherwhise?

Another option would be to add another 'animation' sub-property:

    animation-properties: <property-list>;

    <property-list> |= animatable
    <property-list> |= all
    <property-list> |= IDENT
    <property-list> |= properties( <property-list> [, <property-list> ]* )

whose value affects the supported animated properties.



Samples:

    [1] add support for discrete properties to all animations:

    * { animation-properties: all; }


    [2] animate one property only:

    @keyframes anim { from { color: a; background: b; } to { color: x; 
background: y; }
    #elem { animation: anim properties(background); }




-----Message d'origine----- 
From: Tab Atkins Jr.
Sent: Wednesday, August 01, 2012 9:23 AM
To: François REMY
Cc: Rik Cabanier ; Sebastian Zartner ; Julien Dorra ; www-style@w3.org
Subject: Re: [css3-animations] animate display, other non-animatable 
properties

On Wed, Aug 1, 2012 at 12:14 AM, François REMY
<fremycompany_pub@yahoo.fr> wrote:
> Oh dear, I just noticed you can’t use the 'display' property at all in
> animations; I was really thinking you could and that just the 
> interpolation
> process was going to be ignored.
>
> Therefore, I propose to support ‘animations’ on *any property*; the 
> behavior
> of an animation of an non-animatable property would be to switch the used
> value as soon as the halfway to the next keyframe is reached (i.e. the
> initial value would be mapped to -1, the final one to +1; the used value
> would be the initial one for strictly negative numbers, and the final one
> for positive numbers (0 included)).
>
> This is (strangely) not what has been done for 'visibility' but I feel 
> this
> is what most authors will expect for other properties; we could probably
> extend the definition used for 'visibility' to 'display' from and to 
> 'none'
> because it can make sense for those properties to keep the element visible
> as long as possible. Also, if a way to animate the property is added later
> one, the behavior will probably match more closely the change halfway than 
> a
> change when the next frame is reached only.
>
> This is a breaking change from the current implementations, whose some
> already shipped unprefixed, but this should not be a problem because 
> current
> browser properly ignore those declarations, just like they ignore unknown
> properties.

The fact that they currently ignore them actually means that we
probably can't change our behavior - people may have left properties
in their animations and are now accidentally depending on them not
working.

However, the use-case is very valid.  I think we should be able to
solve this with a new timing function that works for all properties
(and define that the others only work for "animatable" values) -
discrete(<percentage>).  The percentage indicates at what point in the
time it should flip from the start value to the end value.

~TJ

Received on Wednesday, 1 August 2012 08:02:33 UTC