W3C home > Mailing lists > Public > public-fx@w3.org > July to September 2013

[web-animations] Web Animations minutes, 18 / 19 June 2013

From: Brian Birtles <bbirtles@mozilla.com>
Date: Fri, 19 Jul 2013 11:45:12 +0900
Message-ID: <51E8A838.40301@mozilla.com>
To: "public-fx@w3.org" <public-fx@w3.org>
Web Animations minutes, 18 / 19 June 2013

Present: Doug, Shane, Brian
Etherpad: https://etherpad.mozilla.org/ep/pad/view/ro.BTKjE5fjGvu/latest


1. Status updates
2. Spec patches
3. Parabolic cubic-bezier timing functions
4. Revising signature for CustomEffect.sample
5. Inheriting fill mode
6. Making players stop
7. Shorthand properties and dictionaries don't mix :(


- Fill modes
- Blogging:
     Explaining timing groups: 
     (Next: explaining players; keyframes outside [0,1])

- Implementing CSS Animations on Web Animations model in Blink

- Digging holes


Chained timing functions - 
   - Brian to integrate after review
Fill modes - https://github.com/web-animations/web-animations-spec/pull/2
   - See point 5
Keyframes outside [0, 1] - 
   - Brian to get feedback (probably in a couple of weeks' time)


Bug 22483: https://www.w3.org/Bugs/Public/show_bug.cgi?id=22483

Shane: This assumes parabolas that start/end with zero velocity and 
end/start at a particular fixed velocity. I'd rather defer this to the 
Timing Functions specification and develop specific primitives that 
actually capture the range of parabolic effects.

Furthermore, I'm getting increasingly concerned with the use of timing 
functions to emulate things that don't seem to fit into the realm of 
timing functions. Some examples:
  - physics (for more than very trivial effects there are interactions 
between objects. Using timing functions makes this impossible)
  - path smoothing (e.g. 'perfect' timing)

I think this needs some more thought and discussion

Doug: This specific ask seems to be about readaility of CSS (names vs 
bezier points). Some of this could be achieved using CSS Variables.

 > Deferred to separate timing functions spec so we can think about it 
properly (for the reasons Shane raised above).

AI: Shane to follow up with Dean Trower as to the nature of his use 
case. Would a pre-rolled bounce timing function work better?

4. REVISING SIGNATURE FOR CustomEffect.sample

Bug 22487: https://www.w3.org/Bugs/Public/show_bug.cgi?id=22487

Doug, Shane: +1 on passing Animation rather than Player, but shouldn't 
worry until more use cases arrive.


Background discussion: 

Agreed we like the model where children can't fill beyond their parent's 
fill. i.e. if parent says fill:none, it clips children regardless of 
their fill mode.

Furthermore, parents pass down their fill state and fill:none children 
do NOT produce an output when their parents are filling.

Questions remaining:
a) Do we need an 'auto' fill mode?
b) What should the default be?

Regarding (a), the difference between 'none' and 'auto' would be:
'none' - If I'm within my interval (in the strict sense) AND my parent 
is NOT filling, DO produce an output
'auto' - If I'm within my interval (or exactly at the end) DO produce an 

(This definition of being 'within my interval' includes when the parent 
is filling since it is based on the inherited time)

(The 'exactly at the end' condition is so that the following fills forwards:
    <par fill="forwards">
       <animate fill="auto"/>

'auto' is similar to what we currently have specced but with the 
additional handling of interval end points.

Alternative names: 'parent', 'snapshot', 'hold' etc.

When we consider asymmetrical fill modes ('forwards', 'backwards') does 
the behavior when cut-off mimick 'none' or 'auto'? For example, does the 
following fill backwards?

   <par fill="both">
      <animate fill="forwards"/>

It seems we can:
1. Make a choice, e.g. fill:none -> doesn't fill backwards. Seems a bit 
2. Split the properties out. There are a few ways we could do this:

     2a. parent-fill applies to any time the parent is filling
        fill: none | backwards | forwards | both
        parent-fill: hold | ignore

        This lets you do:
        <par fill="forwards">
           <animate fill="forwards" parent-fill="ignore">
        And the <animate> would only fill to the end of the <par> which 
might be useful.

        This would suggest that the default for parent-fill would be 
"hold" so that the following does what you expect:
        <par fill="forwards">
            <animate fill="forwards">

        <par fill="forwards">
            <animate fill="none">
        Would fill forwards (since parent-fill:hold is the default).

        To get the behaviour where you don't extend the child you would 
have to do:
        <par fill="forwards">
            <animate fill="none" parent-fill="ignore">

    2b. Add a property which only applies to when an item may be 
extended by the parent.
        fill-mode: none | backwards | forwards | both
        fill-hold: none | hold

     Obviously, when exposing to CSS (and probably SVG) we'd make it a 
shorthand along the following line:
         fill: <fill-type> (<fill-hold>)*
         fill-mode: none | backwards | forwards | both
         fill-hold: none | hold

     But from the model and API point of view you'd have 2 different 

     The default for fill-hold is less critical in this case since,

        <par fill-mode="forwards">
           <animate fill-mode="forwards">

     Fills forwards regardless of the setting of fill-hold. It really 
depends on the default of 'fill-mode'.

     This doesn't give you the nice feature where you can make an 
animation only fill until the end of its parent though. I guess you 
could achieve this in many cases by simply setting fill:none on the 
parent (but that would prevent you having, for example, some children of 
a sequence extend to the end of their parent and some extend beyond).

    With both 2a and 2b, can we make an animation that:
    - fills forwards if cut-off (i.e. snapshots) but otherwise doesn't 
fill forwards
    - never fills backwards

    i.e. fills forwards in the following case
     <par dur="2s" fill="both">
        <animate delay="-1s" dur="4s" ?? ??>

    but fills in neither direction in the following?
     <par dur="4s" fill="both">
        <animate delay="-1s" dur="4s" ?? ??>

     I think we probably can't. Doing that would require having two 
fill-hold settings. e.g. fill-mode="none" fill-hold="none hold". That 
seems really unlikely and something we could add later if needed so I'm 
not going to bother enumerating it as a possibility.

I'm going to suggest 2b as my preferred option.

I made a diagram with how this looks:

Or there is a fiddle if anyone wants to experiement with alternatives: 

Shane: I could be completely wrong about this, but it seems like 
fill-hold as currently specified:
(1) only impacts the animations to which it is applied
(2) doesn't make anything possible that wasn't already possible. By this 
I mean that if you know where an animation ends with regards to its 
container (a fairly common case) then fill-hold doesn't do anything for 
you. If you _don't_ know, then you get to make some extra assertions 
about the behaviour of the animation, but I'm not sure that these 
assertions are useful in this context.

If this is true, then we should consider fill-hold maybe as a property 
one can set on an animation group (and have it apply to all children) 
rather than on an animation. This lets us force the kind of behaviour 
that is currently specified on subtrees of content.

Brian: Regarding (b)--the default fill mode--we have the following 
- CSS and SVG use a default fill mode of 'none' and it would be 
difficult for authors if they translate a fragment of markup into script 
calls (or vice-versa) and it starts behaving differently, sometimes in 
subtle ways.

Shane, Doug: CSS transitions have an implied fill mode of 'both' :-D
Shane: I'm not overly concerned about the script defaulting differently 
to CSS / SVG. It already does in a myriad of ways.

Doug: In Chrome, animation-fill-mode appears to be set about 30% as 
often as animation-duration.

- Our API uses a default fill mode of 'forwards' since we observed that 
is is often most useful for scripted calls, at least when using the 
Element.animate shortcut
- It is *probably* most useful to make groups fill:both by default so 
then when you wrap up your animations for sequencing purposes their 
behaviour doesn't change.

Some possible approaches:

i. fill-mode:none is the default. Element.animate overrides this with 
    - Wrapping an animation with fill:forwards in a par group without 
specifying the fill mode causes it to get clipped.

Doug: I'd prefer that element.animate didn't behave differently.

ii. Introduce fill-mode:default. For timing groups this is 
fill-mode:both, for animations this is fill-mode:none. Element.animate 
overrides this with fill-mode:forwards.

Shane: I actually think I'd rather go with iii. always default fill-mode 
to both. If there is violent disagreement with this then I prefer what 
we currently have, followed by i., followed by ii.
Doug: +1 but I'm not too worried

Brian: In both cases I think I'd suggest fill-hold:none be the default 
and you have to opt-in to the snapshotting behavior? That's probably 
something that's easy to change with implementation feedback.

Shane: Definitely fill-hold:none should be the default.

Brian: One more alternative, set the fill-hold state on the parent. We 
initially avoided this because we thought there may be some children 
that should hold and some that shouldn't. How important a use case is 
this? There are ways to get this behavior by adding additional animations.

Shane: As mentioned above, I've come around and think this is a good 
idea now.

 > For now, let's incorporate the fill-mode changes into the spec minus 
fill-hold. When Steve returns we'll revisit fill-hold and see if it 
could be put on the group instead.

Shane: what about some kind of fill-mode: inherit that returns 'none' 
for root nodes? This way, at least trees of animation can be set to 
fill-mode: forward in one place rather than everywhere.

Further discussed defaults for fill-mode. Couldn't decide what is best 
here. In summary:
  - fill:none -- mimicks other specs; seems more natural in some cases.
  - fill:both -- in practice, is often more useful. Making authors 
specify this all the time is burdensome.

AI: Shane to write a CONCISE email about default fill mode to send to 
ww-style, public-fx, tab's blog (?), Alex's G+ feed, etc. etc.


I think players should stop when their source content finishes.

* It parallels what real video players etc. do
* The current time of a player should represent the position within the 
source content.
* Having a notion of stopping allows for defining events on players 
('onend' etc.) or making them then-able
* It allows for defining a reverse() method which, if you call twice, is 
a no-op

- What is the paused state when a player stops?
- What happens if I update the player's source content after it has stopped?

(Related issue: we did decide, right, that setting the startTime doesn't 
reset the time drift... I think that's a bit surprising. I think we 
should expose the time drift as "pausedTime")

A few models:

a) When we reach the end, we auto-pause.

If it gets longer, start playing from previous end to new end; if it 
gets shorter, just jump to new end. Need to define how this works for 
batch changes.

At a slightly more detailed level this operates like pausing in that we 
keep accumulating a timeDrift like we normally do when paused. There are 
two exceptions though: if the source content gets shorter though we 
increment the timeDrift by the difference in length. If the source 
content gets longer we automatically unpause.

This gives intuitive results in most cases and also produces sensible 
values for "paused", "pausedTime", "currentTime" etc.

The main issue is bulk changes. If you change the source content so it 
gets shorter and then make a subsequent change that makes it get longer 
you'll find you'll find it jumps back and starts playing from the 
shorter end time. The bad news is this is a different result than if you 
just made the source content longer. The good news is you should get the 
same result regardless of the order of operation.

b) Just ignore the change: it has stopped.

The paused state is true automatically but doesn't automatically reset. 
You'd have to do that manually *and* update the current time to get it 
to play again (since setting the pause state without changing the 
current time would make it auto-pause again).

That last point is a bit odd. It's also problematic because if you got a 
sample before you added any content to your player (or any content with 
greater than zero duration) you'd get stuck. That could be really 
problematic for media which might initially have zero duration but after 
buffering get a longer duration.

c) Don't auto-pause, just cap the current time

In this model, the paused state doesn't get set and nor does the 
pausedTime change. But the reported current time is never greater than 
the end of the source content.

In effect we change the formula for the current time as follows:

current time = min((timeline time - start time) * playback rate - time 
                                 source content start delay + source 
content active duration)

Under this approach if you change the length of the source content to 
make it longer, you might, for example, jump to half way through the 
extended part or you might jump to the end depending where the "actual" 
current time is up to.

One advantage of this approach is that you don't run into changes in 
behavior due to the timing of changes to the source content.

Personally I wonder if there's some way to tweak approach (a) to remove 
some of the issues there.

d) Doug: I think we want a model with these properties:
- current time should stop increasing when we reach the end of the 
source content
- setting a shorter source content should not change the current time
- setting a longer source content should not change the current time

Shane: I think Doug's right. This is basically a hybrid of (a) and (c) 

Brian: Sounds good. Does it auto-unpause when the source content gets 
longer? I think it has to or else you have the problems associated with (b).

Shane: Alternate wording: Players have a time bound that extends from 
startTime to endTime. Players do not advance currentTime if it is 
outside their time bound.
   - paused is false when this happens (i.e. we don't automatically 
switch the pause state)
   - you can still set currentTime to a time outside the bound - it just 
won't advance after
     that happens

Brian: How about exposing the time drift? I think people will get 
tripped up because that's hidden. But what to call it?

Shane: Yes, let's expose the time drift.

Brian: time drift is a bad name. Should it be positive or negative? 
pausedTime is obviously positive, but it doesn't indicate that seeking 
(or this non-advancing behaviour) is incorporated in the value.

timeOffset? timeLag?

 > timeLag

RESOLVED: 'time drift' to be renamed 'time lag' and exposed as timeLag.

A further question which applies  to all models: What happens when you 
play in reverse? Do you stop advancing when you hit currentTime=0 or 
when you hit the start of the source content?

 > currentTime = 0

How about when you have a negative delay, a positive playback rate and 
you set the current time to prior to the negative delay? Or in the 
negative delay?

Shane: For currentTimes before 0 then (1) the currentTime should not 
advance and (2) the source should behave as if it is in its backwards 
fill mode, fixed at a local time of 0.

Brian: A bit concerned about the play head getting stuck when you change 
the source content.

 > We'll think about it a bit more.


In CSS, ordering dictates priority within a style rule. For example

background: red;
background-color: blue;
  -> background color is blue

background-color: blue;
background: red;
  -> background color is red

Per the JS specification, Objects don't have a defined ordering, so we 
can't use this. Even if we did define an ordering (e.g. alphabetic), 
this is unlikely to match the in-text-order ordering that the author 

1. Shorthand or longhand wins, the others would be discarded.
2. Only one property per keyframe.
3. List of property, value pairs.
4. Some other well defined order.

Actually current order for accessing properties of a passed in keyframe 
object is well-defined (basically alphabetic):

The problem is our animation priority model needs to address shorthands. 
We could define a blanket ordering (e.g. shorthands before longhands). 
Or we could drop shorthands from web animations altogether--say they are 
expanded at a higher level.

AI: Brian to investigate when shorthands are expanded in Gecko.

Next meeting: Thurs July 25 18:00 PDT / Fri 26 July 11:00 AEST / Fri 26 
July 10:00 JST @ https://etherpad.mozilla.org/u6hQRTEyzi

Past meetings: http://www.w3.org/Graphics/fx/wiki/Web_Animations/Meetings
Received on Friday, 19 July 2013 02:45:42 UTC

This archive was generated by hypermail 2.3.1 : Monday, 22 June 2015 03:33:50 UTC