RE: Animations issues (was Re: [CSSWG] Minutes Telecon 2012-12-12)

[L. David Baron:]

[snip]

> >   sylvaing: This bug is about prose in the spec along the lines of...
> >   <sylvaing> http://lists.w3.org/Archives/Public/www-

> style/2011Dec/0144.html
> >   sylvaing: Spec says that animation-start events are dispatched for
> each
> >             animation-name in the list, but impls don't fire if the
> >             @keyframes rule is empty.
> >   smfr: I think we should define more strictly when an animation runs,
> >         and just say that empty keyframes don't run an animation.
> >   TabAtkins: Is there any compat impact for just making an empty
> @keyframes
> >              invalid?
> >   sylvaing: I was thinking about that.  There's a potential compat case
> -
> >             if a keyframe "foo" is overridden by another "foo" which is
> >             empty, it'll hide it.
> >   smfr: I think it makes sense to have it be valid, so you can start
> with
> >         an empty @keyframes rule and fill it with script.
> >   TabAtkins: Makes sense.
> >   smfr: I think we can define that a side-effect of an animation running
> >         is that animations fire, and empty keyframes don't run.
> >   sylvaing: Missing 0% and 100% keyframes are filled in by the UA, so
> >             one's never actually empty, right?
> >   TabAtkins: Those don't show up in the OM, though - we just fill in
> >              values to the actual animation.
> >   sylvaing: Okay, so I'm okay with that.  We can specify that an
> animation
> >             runs only if it has one or more valid keyframes.
> >   RESOLVED: Animations only "run" (fire start events, etc) if they have
> >             at least one valid keyframe.
> 
> What's a valid keyframe?  Is it:
>  (a) one that has a valid keyframe selector between 0% and 100%
> (inclusive)
>  (b) one that has (a) and also valid declaration inside it, or
>  (c) one that has (b) plus the property is interpolable through
>      the whole animation
> 
> I would prefer (c), since it's equivalent to whether the animation is
> actually animating any properties, at least assuming we define the
> behavior of non-interpolable segments as removing the property from the
> animation (which is as I proposed in
> http://www.w3.org/mid/20110422015502.GA28856@pickering.dbaron.org

> right after raising the issue, but is not addressed in the current spec
> draft, and is hopefully listed in the list of issues though I can't check
> since I'm writing this offline).

As you noted on the call, this is the harder issue of the bunch. I will
point out that last week's discussion did not really dive into what causes 
an animation to run. We did discuss whether an empty @keyframes rule was 
valid and may 'hide' preceding @keyframes rules with the same name. Then we 
discussed whether such an empty rule should trigger the side-effects of 
animation execution such as start/end events firing.

We agreed at the time that such empty @keyframes rules would not run. After
today's call and some more thinking, I'll try to describe my mental model 
thus far: an animation runs on an element when *all* the following are true: 

1. The display property computes to a value other than none for the element and 
all its ancestors
2. The computed value of the animation-name property is updated either:
 - from 'none' to a set of 1+ valid animation names OR
 - from a set of 1+ valid animation names to a different set of valid 
 animation names
3. One of the animation names introduced by step #2 matches that of the animation's
 @keyframes rule.
4. The animation-duration property resolves to a duration for this animation that 
is >0s

If all the above are true then the animation executes and related events fire
at the appropriate interval.

This means the following:

@keyframes emptiness {}

#test {
 display:block;
 animation-name: emptiness;
 animation-duration: 3s;
}

...would execute the emptiness animation. Nothing about #test's computed property
values would change but animation start/end events would fire 3 seconds apart.

I think last week's resolution and your preferred resolution above imply that we 
are adding the following requirement:

5. The animation's definition specifies at least one keyframe rule with a valid 
keyframe selector and declaration block; the declaration block must declare at 
least one valid animatable property value.
 
If we add #5 then the emptiness animation above would not run; no events would be
fired. The following @keyframes rules would also not run:

@keyframes empty-decl-block {
 50% {} /* Empty declaration block */
}

@keyframes invalid-decl {
 50% {
  display: gridiculous; /* invalid declaration -> like empty declaration block */
 } 
}

@keyframes not-animatable {
 to {
  animation-duration:5s /* Valid property and value but does not animate */
 }
}

Is that a complete description of the change?

I will note current implementation behavior using the @keyframes rule names above;
Yes/No indicates whether animation start/end events fire:

+------------------+------+----------------+-----------+
|       Rule       | IE10 | Firefox Aurora | Chrome 23 |
+------------------+------+----------------+-----------+
| emptiness        | No   | No             | Yes       |
| empty-decl-block | No   | No             | Yes       |
| invalid-decl     | No   | No             | Yes       |
| not-animatable   | No   | No             | Yes       |
+------------------+------+----------------+-----------+

Though my test was simplistic, it appears that Firefox and IE10 
may already conform to David's c) preference above. Chrome always 
executes the animation.

Though I can make the case both ways I can't quite come up with a use-case
or reason to strongly prefer one over the other.

I have re-opened the bug.

(Whatever we resolve I think we want to define the conditions of animation
execution in the spec in a manner similar to the above).

> 
> >   <sylvaing> https://www.w3.org/Bugs/Public/showbug.cgi?id=14785

> >   sylvaing: Next is display:none effects.
> >   sylvaing: display:none stops animations.
> >   sylvaing: We didn't clearly write down when you go from display:none
> >             to non-none.
> >   sylvaing: Our assumptions in IE is that animations will start, but not
> >             transitions.
> >   sylvaing: I think it's reasonable to agree on the animations thing
> now,
> >             but maybe not transitions without dbaron around.
> >   TabAtkins: I agree about animations.
> >   RESOLVED: When an element changes from display:none to display: non-
> none,
> >             animations start immediately.
> 
> Presumably this also applies to any ancestors of the element being
> display:none.  And presumably also to any of the other things that might
> remove it from the rendering tree:  perhaps some of the other things
> mentioned in http://dbaron.org/cdi-req/#mixing-elements .  We should
> probably get that stuff defined at some point.
> 
> Does changing an element or its ancestor to display:none stop the running
> animations as well?  That seems like a potential interop danger given that
> we don't (and, I believe, shouldn't) define when style flushes occur.

The latest ED includes this:

# Setting the display property to ‘none’ will terminate any running animation 
# applied to the element and its descendants. If an element has a display of 
# ‘none’, updating display to a value other than ‘none’ will start all 
# animations applied to the element by the ‘animation-name’ property, as 
# well as all animations applied to descendants with display other than ‘none’.

I believe this covers your comment, though I'm not 100% happy with the wording.
It seems a bit heavy so suggestions welcome.

> 
> >   <sylvaing> https://www.w3.org/Bugs/Public/showbug.cgi?id=14774

> >   <sylvaing> http://lists.w3.org/Archives/Public/www-

> style/2011Oct/0214.html
> >   sylvaing: This is about adding animation-play-state:paused when an
> >             animation isn't yet running.
> >   sylvaing: Today, FF and IE10 freeze the animation on its first frame
> >             (or don't show anything, if it's delayed).
> >   sylvaing: Related, what if you're in delay, and you flip to pause.
> >   TabAtkins: I think dbaron said that FF just freezes the remaining
> delay
> >              and continues with it when you unpause.
> >   sylvaing: [checking whether animation-fill-mode affects the
> >              immediately-paused animation]
> >   TabAtkins: Does it fire an animationStart event?  I think it should,
> >              since it's already displaying the start of the animations.
> >   sylvaing: Based on quick testing, looks like IE and FF don't.  But we
> >             think that it should?
> >   TabAtkins: yeah.
> >   sylvaing: What effects would this have on elapsedTime?  I think it's
> >             relative to the animation, not absolute.
> >   smfr: I think so - the time the animation has already been running.
> >   RESOLVED: An initially-paused animation is still started (fires start
> >             events, etc.)
> >   <smfr> and it may be paused during the delay phase
> >   RESOLVED: Animations can be paused during their delay phase, which
> >             freezes the remaining delay to be applied after it unpauses.
> 
> Sounds good.  Firefox currently needs to update to match a previous
> resolution on delay here.
> 
> >   <sylvaing> https://www.w3.org/Bugs/Public/showbug.cgi?id=14787

> >   sylvaing: Is it intentional that animation-play-state can't be applied
> >             in the shorthand?
> >   smfr: I think it was intentional, because of potential ambiguity
> >         collision with animation names, and low possibility of
> usefulness.
> >   sylvaing: I'm fine with that.
> >   RESOLVED: animation-play-state is not in the shorthand on purpose
> 
> Does that mean it's not specifiable in the shorthand, or not reset by the
> shorthand?  I'm fine with not being specifiable in the shorthand but
> always being reset to 'running', but I'm not ok with the idea that the
> shorthand doesn't reset 'animation-play-state'.

Since we resolved today to include animation-play-state in the shorthand
after all I've reopened the bug.

> 
> >   <sylvaing> https://www.w3.org/Bugs/Public/showbug.cgi?id=14786

> >   sylvaing: The behavior of animation-play-state as a list isn't
> defined.
> >             I imagine it's just the same as the other properties (cycled
> >             until it reaches the length of animation-name list)?
> >   RESOLVED: animation-play-state has the same list behavior as the other
> >             animation properties, matching the length of animation-name.
> 
> sounds good
> 
> >   <sylvaing> https://www.w3.org/Bugs/Public/showbug.cgi?id=20092

> >   sylvaing: Tab had a proposal to add the ability to have "adjacent"
> >             keyframes, which are explicitly next to each other.
> >   sylvaing: Today you have to hack around it with "50%" and "50.00001%"
> >             or similar.
> >   florian: Sounds useful, but we have to finish the current level, so
> >            I'd prefer to delay it.
> >   fantasai: Agreed.
> >   RESOLVED: Look into "adjacent keyframes" for level 4, but not for the
> >             current level.
> 
> sounds good.
> 
> -David
> 
> --
> 𝄞   L. David Baron                         http://dbaron.org/   𝄂
> 𝄢   Mozilla                           http://www.mozilla.org/   𝄂

Received on Wednesday, 19 December 2012 20:50:58 UTC