Re: Comments on CSS Animations

Hi Cameron,

On 28/02/2009, at 12:39 PM, Cameron McCormack wrote:

> Hi CSS WG.
>
> As promised, here are some comments on CSS Animations.
>
>
> The production for keyframes-rule in the grammar is:
>
>  keyframes-rule: '@keyframes' IDENT '{' keyframes-blocks '}';
>
> but the examples seem to use single quoted names instead of IDENTs for
> the keyframes rule name.

This is an error. The examples should use IDENTs.


>
> CSS Animations defines how it applies animated values better than
> Transitions does.  (I think this wording should go into Transitions,
> since Animations says that it extends Transitions.)

Yes, I agree.

>
> As I mentioned earlier, SVG animations of CSS properties are applied  
> by
> modifying the override style sheet of the element, which then  
> contribute
> to the computed value of the element. These can be overridden with
> !important rules.  CSS Animations bypass the normal computation rules
> and just override the computed value of the property, and so would  
> take
> precedence over SVG animations and any !important rules.  Do you think
> there might be advantages to integrating with the regular computed  
> value
> computations as SVG does (thinking out loud)?
>
> I wonder also what the effect would be of the following:
>
>  <svg xmlns="http://www.w3.org/2000/svg">
>    <circle r="100" style="fill: blue; transition: fill 1s">
>      <set attributeName="fill" to="red"/>
>    </circle>
>  </svg>
>
> Since <set> will modify the <circle>’s override style sheet, that  
> would
> trigger the transition, I guess.  If the <set> were an <animate>,
> there’d be many (useless) transitions per animation tick.

I agree this needs to be clarified.

> Also, how do CSS Transitions and Animations interact?

Animations trump transitions. That is, a transition will not run if  
the property is currently being animated.

>
> The term “intrinsic style” isn’t one that I’m familiar with from CSS.
> Is it the computed value of the property as derived using the regular
> CSS cascade/computation rules? If so, then the spec should say so.

Agreed.


>  In the case of multiple animations specifying behavior for the same
>  property, the animation defined last will override the previously
>  defined animations.
>
> This is different from SVG animation, where the most recently begun
> animation is the one that takes precedence (or later in document  
> order,
> if two start at the same time; it’s moved to the top of the sandwich).
> Are there good reasons to be different here?

Mostly because this is the way CSS usually works (last defined wins).  
Also note that you only have one definition of CSS animations on an  
element at any time - the value of the animation-name property. In  
effect, all animations happen at once. This is a little different from  
SVG/SMIL.

There might be some specification needed for what happens when two  
animations alter the same property and have offset delays. I'll look  
into it.

>  The start time of an animation is the latter of two moments: the time
>  at which the style is resolved that specifies the animation, or the
>  time the document’s load event is fired.
>
> In SVG, the animation timeline can be defined to begin either at
> document load or as soon as the document element has been  
> parsed[1].  In
> SVG documents where timelineBegin="onStart", t=0s in the document
> timeline wouldn’t correspond to the first time when CSS animations can
> apply.  Would it be worth referring to the document timeline here, so
> that such animations are synchronised (but falling back to the time of
> the document’s load event firing when a document timeline isn’t
> defined)?

I think you raise an important general point - that CSS animation does  
not (yet) describe synchronisation, and therefore doesn't talk about  
timelines (document or otherwise). I think your suggestion sounds good.

>  Once an animation has started it continues until it ends or the
>  ‘animation-name’ is removed.
>
> s/‘animation-name’ is removed/actual value of the ‘animation-name’
> property no longer references the keyframes rule/, or some such.

Agreed.


> I suppose a keyframes rule with a name of “none”, “inherit” or  
> “initial”
> could never be referenced from ‘animation-name’.  Maybe the section
> describing the keyframes rule should mention this or disallow those
> names.

That's true, and it should. (It does say something about "none" always  
meaning "do not animate" even if there is a keyframes rule with that  
name)

>
>  The values used for the keyframes and animation properties are
>  snapshotted at the time the animation starts. Changing them during  
> the
>  execution of the animation has no effect.
>
> Presumably this doesn’t apply to ‘animation-play-state’.

Correct. It should be clear that it is also snapshotted. Actually,  
we're trying to deprecate that property.

> What happens if ‘animation-name’ has the value “a, none, b”, say?  Are
> animations a and b applied?

Yes. Since it is a list (like background) then a and b still apply. If  
you want no animation, then you should have a single "none" value (or  
multiple "none" values, if you really want to get the point across :)

>  A ‘animation-timing-function’ defined within a keyframe block applies
>  to that keyframe, otherwise the timing function specified for the
>  animation is used.
>
> Does it apply to the interpolation from the previous keyframe to that
> this keyframe, or from this keyframe to the next?

It's from this keyframe to the next keyframe. In other words, a timing  
function on 100% doesn't do anything.

>  Also, what happens
> when an ‘animation-timing-function’ in the keyframe rules specifies a
> list of timing functions?

To be consistent with the other places we use lists in properties, the  
first timing function in the list will be used.

In other words, it works the same as having a list of timing functions  
specified outside the keyframes in the case where you only have one  
animation.

>
>
>  We are considering removing ‘animation-play-state’ since its  
> behaviour
>  can be replicated using other techniques. For example, by querying  
> the
>  computed style, removing the animation and then setting style.
>
> I think it would be easier for authors to set a property to pause the
> animation, rather than the workaround suggested.  Of course,
> ‘animation-play-state’ has the same usability issues with all of the
> Transitions and Animations properties in that if you want to pause a
> single animation, you have to do some string tokenisation to extract  
> out
> the relevant “running” value to replace with “paused”.

Removing this property is an attempt to simplify the first pass of the  
specification. Also, it isn't clear if you would always want to  
"pause" the animation and then have it continue with the same  
parameters, or tweak things in the paused state. In other words, it is  
hard to know if pausing is what people want.

Personally, I'm ok either way.

> The ‘animation’ shorthand is defined to be:
>
>  [<animation-name> || <animation-duration> ||
>   <animation-timing-function> || <animation-delay> ||
>   <animation-iteration-count> || <animation-direction>]
>  [, [<animation-name> || <animation-duration> ||
>      <animation-timing-function> || <animation-delay> ||
>      <animation-iteration-count> || <animation-direction>] ]*
>
> What if the property were set to “a 1s 2s”?  Would the 1s be the
> duration or the delay?  (Same goes for the ‘transition’ property.)
> Similarly, if it were set to “ease-in” would that be the animation  
> name
> or the timing function?

This issue was reported on transitions too. The resolution (not  
reflected in the specs yet) is to use similar syntax to font. ie. a 1s/ 
2s.

However, that doesn't solve your timing function question. I'm tempted  
to remove the shorthand, or at least disallow anything ambiguous  
(probably means no timing-function).

>  Therefore an event will be generated for each animation-name value  
> and
>  not necessarily for each property being animated.
>
> If ‘animation-name’ were “a a” would an animationstart event be fired
> twice or once for the “a” animation?

In this case there would only be one animation, and thus one event.

> As with transitionend, the animationstart, animationeend and
> animationiteration events should define their default behaviour so  
> that
> their being cancelable makes sense.

Agreed.

> The definition of elapsedTime says:
>
>  For an “animationstart” event, the elapsedTime is always zero.
>
> Does it make sense then to have elapsedTime omitted from the context
> info of animationstart?

Maybe, but this doesn't seem like a big deal.

> The CSSRule.KEYFRAMES_RULE constant value conflicts with SVG’s
> COLOR_PROFILE_RULE constant value[2].  (Is there a registry for these
> values, or a defined process for having values allocated?  Same  
> question
> for, say, DOMException codes.)

You're right, and it is a pain that there isn't a registry (exception  
codes also). I'll change the constant values in this spec, but maybe  
we need to either start a registry or reserve blocks for particular  
specifications. ie. we'll take 100-200?

> CSSKeyframeRule.keyText is defined as:
>
>  This attribute represents the key as the string representation of a
>  floating point number between 0 and 1. If the value in the CSS style
>  is from this value will be 0, and if the value in the CSS style is to
>  this value will be 1.
>
> What if the keyframe selector was a list of values?  Is it a comma
> separated list of floats between 0 and 1?

Good point. We could either return a comma-separated list or have  
duplicate CSSKeyframeRule entries. Which do you suggest? I'm tempted  
to stick with comma-sep list.

> The ‘key’ parameter to CSSKeyframesRule.deleteRule is defined as:
>
>  The key which describes the rule to be deleted. The key must resolve
>  to a number between 0 and 1, or the rule is ignored.
>
> Not sure what it means to “resolve” in this context.  If my keyframe
> rule had a selector “20%,30%” and I pass in "30%,20%" will it remove  
> the
> rule?  What about “0.2,30%” or just “20%”?  Similarly for findRule().


Yeah, this needs to be clarified. I assume you would want it to find  
the rules, since that is more useful than not.

Dean

Received on Tuesday, 3 March 2009 20:49:28 UTC