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

On Wednesday 2012-12-12 19:47 -0800, fantasai wrote:
> Animations
> ----------
> 
>   * fantasai notes dbaron is not here today

(And, for the record, I sent regrets to the member-only list a week
in advance, though those regrets were not noted in the minutes.)

I'd appreciate if we could come back to the issues I raise below on
tomorrow's telecon.

>   <sylvaing> https://www.w3.org/Bugs/Public/showbug.cgi?id=16116
>   <sylvaing> http://dev.w3.org/csswg/css3-animations/#animations
>   sylvaing: This one is a terminology issue that Dirk noticed in the spec.
>   sylvaing: There's a diagram that talks about "intrinsic style", but
>             doesn't define what that means.
>   TabAtkins: Seems like what it means is the style without Animations
>              applied
>   sylvaing: The intent of the bug was to say that it should point to an
>             existing phrase.
>   TabAtkins: I don't think we have one. Maybe just use a phrase.
>   <darktears> initial style -> final style (after animation run)
>   <fantasai> static style / animated style?
>   smfr: Do we have a document listing the terms for th existing style levels?
>   fantasai: Cascade.
>   <fantasai> http://dev.w3.org/csswg/css3-cascade/
>   TabAtkins: Even if we don't define a new term, the diagram is wrong and
>              should have a short phrase rather than "specified" and
>              "computed" style.
> 
>   <sylvaing> https://www.w3.org/Bugs/Public/showbug.cgi?id=14784
>   sylvaing: next is some grammar issues.
>   sylvaing: One is user-defined ident case-sensitivity, which is still
>             pending.
>   sylvaing: Another is that the animation and transition specs both define
>             the timing functions, and we should really define it only once.
>   sylvaing: Can we define that Animations is dependent on Transitions for
>             this?
>   [several]: yeah
>   RESOLVED: Transitions defines the timing functions, Animations has
>             normative dependency on Transitions for them.

sounds good.

>   sylvaing: Now about the user-ident stuff, how is that going?
>   fantasai: jdaggett just wrote a bunch of tests for it, and posted to the
>             list.
>   <fantasai> http://lists.w3.org/Archives/Public/www-style/2012Dec/0149.html
>   glazou: I pinged i18n about it too.
> 
>   <sylvaing> https://www.w3.org/Bugs/Public/showbug.cgi?id=15251
>   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).

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

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

>   <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 02:37:45 UTC