Re: Apple's Proposal for CSS Animation

Some comments on some parts of the proposal below; I jumped around
and didn't read everything in detail.

On Wednesday 2007-11-07 11:34 -0600, David Hyatt wrote:
> 2 Transitions

> Every CSS property definition should specify the following additional 
> information: whether or not its value is animatable and how it should 
> animate. Animatable properties are all of those which allow values of the 
> type <integer>, <number>, <length>, <percentage>, <color>, <time>, <angle> 
> or <transform-list>. See Coordinate System Transformations for more 
> information about how transforms animate.

How do transformations of <color> values work?  Should the
'color-interpolation' property [1] from SVG be used?  (Its
definition seems a little vague to me, although fixable by turning a
few things into hyperlinks.)

[1] http://www.w3.org/TR/2003/REC-SVG11-20030114/painting.html#ColorInterpolationProperty


It seems like the description of which properties are animatable
might be better expressed as a constraint on the used value.  For
example, 'line-height''s used value is a length, so it should be
animatable (although animating from a <number> to a <length>
specified value could have interesting effects on descendants).
And, likewise, animating 'background-position' or 'vertical-align'
could be possible.  (Although I'm not sure whether it's worth
dealing with this complexity in the first version.)

But some things are harder.  Animating 'outline-color' from 'red' to
'invert' might be interesting (per-pixel animation?).  But what does
it mean to animate 'z-index' from 'auto' to '7'?  (When does the
element create a new stacking context?)  (Most other 'auto' values
seem a good bit easier to animate, since the used value is generally
a length.)

I'm not saying it shouldn't be done, but this needs a clearer
definition of which properties are animatable, and, when they are,
how.  (You have a few examples below, but not really definitions
that could be extended to all cases.)


Also, is "Coordinate System Transformations" supposed to be a
hyperlink?  I can't find what it's referring to.



> Each of the transition properties accepts a comma-separated list, allowing 
> multiple transitions to be defined, each acting on a different property. In 

Detached comma-separated lists that line up with each other make me
queasy.  (They don't cascade well, and they seem difficult to author
unless you use the shorthand, which can get complex pretty quickly.)
A possible alternative is using @-rules to define the whole mess and
then referring to a single @-rule, although I'm not sure if that's
any better in this case.

(If the lists are different lengths, you should clearly say what
happens.  Does one property determine the length and the others repeat
or fill to match it?)

> Applies to:	block-level and inline-level elements

Why do all the properties apply only to blocks and inlines?  It
seems reasonable to animate the color of a table row.

> Inherited:	no

Inheritance here is a little tricky, I think.  Even though these
properties aren't inherited, they have to apply to any element to
which the property being animated is inherited.  In some cases this
is nontrivial, since the two values (initial and final) would have
to be inherited separately to the descendants in order to animate,
say, a transition from 'line-height: 1.2' to 'line-height: 30px',
and each descendant would have to animate between the resulting pair
of computed values.

The same complication arises when explicit 'inherit' is used on a
descendant of a property being animated.  For example, if a
child has 'width: inherit' and its parent is animating from 'width:
auto' to 'width: 300px', you need to propagate separately to get the
correct animation.

I'm not sure if we want this complexity in the first version.  But
I'm also not sure how to avoid it, since I expect 'left', 'top',
'right', and 'bottom' are among the most useful properties to
animate, and they have the latter problem.  One way to avoid the
complexity is to say that in those cases, you get a jumpy animation
defined in a particular way in place of the smooth animation one
might expect.  However, a rule like that is harder to fix later.


For 'transition-property', it may be worth mentioning that naming a
shorthand property causes all of its subproperties to be animated.
(That may even influence what you want to call the "Computed value"
of the property.  I'm not sure which way is better in terms of the
DOM computed style APIs (which don't even correspond to "Computed
value" anymore).)

> 2.5 The 'transition' Shorthand Property

> Name:	transition
> Value:	[<transition-property> || <transition-duration> || 
> <transition-timing-function> || <transition-name> [, [<transition-property> 
> || <transition-duration> || <transition-timing-function> || 
> <transition-name>]]*

You're missing a "]" after the first occurrence of
"<transition-name>".

> Computed value:	Same as specified value.

The computed value line for 'transition' should probably also say
"see individual properties".

> 3 Keyframes

> The keyframe selector for a keyframe style rule consists of a 
> comma-separated list of percentage values or the keywords 'from' or 'to'. 
> The selector is used to specify the percentage along the duration of the 
> animation or transition that the keyframe represents (the block of property 
> values declared). The keyword 'from' is equivalent to the value 0. The 
> keyword 'to' is equivalent to the value 100%.

Are values outside of 0-100% clamped to that range or discarded?

> The keyframe declaration for a keyframe rule consists of properties and 
> values. Properties that are not transitioning or animating are ignored in 
> these rules, with the exception of 'transition-timing-function' and 
> animation-timing-function'.

Could you reference section 3.1 (Timing functions for Keyframes) here?
(I'd written a comment here, but most of it was answered there.)

> The @keyframes rule that is used by a transition or animation will be the 
> last one encountered in sorted rules order that matches the name of the 
> transition. @keyframes rules do not cascade; therefore a transition or 
> animation will never derive keyframes from more than one @keyframes rule.

It might be worth mentioning explicitly that this is the last
@keyframes rule in the style sheet (rather than the last one before
the declaration that uses the rule).

> 3.1 Timing functions for keyframes
>
> A keyframe style rule may also declare the timing function that is to be 
> used as the transition or animation moves to the next keyframe.

So if it's used for some rules and omitted for others, the ones that
omit it will get the computed value of the relevant '*-timing-function'
property instead?  If that's correct, I think it's worth saying so.

> 4.7 The 'animation-delay' Property
>
> The 'animation-delay' property defines when the animation will start. It 
> allows an animation to begin execution at some period of time after it is 
> applied. An 'animation-delay' value of 'now' means the animation will 
> execute as soon as it is applied. Otherwise, the value specifies an offset 
> from the moment the animation is applied, and the animation will delay 
> execution by that offset.

What does it mean for an animation to be applied?  This should be
defined both in the context of page loading and in the context of
dynamic changes to the animation properties.

> If the value for 'animation-delay' is a negative time offset then the 
> animation will execute the moment it is applied, but will appear to have 
> begun execution at the specified offset. That is, the animation will appear 
> to begin part-way through its play cycle. In the case where an animation 
> has implied starting values and a negative 'animation-delay', the starting 
> values are taken from the moment the animation is applied.

What are implied starting values?

-David

-- 
L. David Baron                                 http://dbaron.org/
Mozilla Corporation                       http://www.mozilla.com/

Received on Monday, 19 November 2007 05:17:51 UTC