Re: [web-animations] Default fill mode

Hi Brian,

Of the four options you propose for Element.animate, it feels like option
(2) would lead to inconsistency when moving from Element.animate to new
Animation (i.e. re-introduce the problem we are trying to avoid), and
option (4) is a very heavy-weight solution. Hence I'm inclined to prefer
option (1) (leave as it, Authors just have to work harder to use
Element.animate) or option (3) (add Element.animateTo as an extra

Perhaps option (1) for now, and reserve the right to introduce (3) in
response to feedback?


On Tue, Aug 6, 2013 at 10:35 AM, Brian Birtles <> wrote:

> Hi Tab,
> Thanks very much for your feedback. That's very helpful. I have one
> further question below.
> (2013/08/03 2:58), Tab Atkins Jr. wrote:
>> We considered three options:
>>>   (1) choose a default fill mode of 'none' to match CSS and SVG?
>>>   (2) choose a default fill mode of 'both' because it makes the API
>>> easier to
>>> use?
>>>   (3) add an 'auto' fill mode that defaults to 'none' for animations
>>> (matching CSS and SVG) but 'both' for groups (making it easier to switch
>>> animations from 'none' to 'both')?
>>> After some discussion we think (3) is probably the best option but if
>>> anyone
>>> has any feedback regarding this, we would be glad to hear it.
>> Yes, do #3.  Groups shouldn't by default impose clamping behavior on
>> their contained animations, and we should match the SVG/CSS default
>> for the actual animations, to minimize surprise.
> One drawback of this approach, however, is that we have an Element.animate
> interface where we think authors will expect fill-forwards behaviour.
> The interface looks like this:
>   // Move elem to 100px over 3 seconds
>   elem.animate({ left: '100px' }, 3);
> The equivalent in jQuery is:
>   $(elem).animate({ left: '100px' }, 300);
> However, with jQuery, like most script libraries, the effect will continue
> to apply after the animation has finished.
> To produce that behavior in the current Web Animations API with a default
> fill mode of 'auto' (='none' for animations), you would have to write:
>   elem.animate({ left: '100px' }, { iterationDuration: 3, fillMode:
> 'forwards' });
> Now, we can probably tweak the naming here and make it a bit shorter:
>   elem.animate({ left: '100px' }, { duration: 3, fill: 'forwards' });
> (I've suggested renaming 'iterationDuration' to 'duration' before but
> no-one seemed interested. Having now noticed that jQuery uses 'duration'
> for this I think it's worth re-considering.)
> But it's still quite a bit to type for a common effect.
> So, we have a few options:
> (1) Leave as is. Authors just have to type more / set up macros / write
> wrapper libraries to do this for them.
> (2) Make Element.animate use a different default fill mode than elsewhere
> in the API (e.g. the Animation constructor).
> (3) Add a further shortcut which provides this different default
> behaviour, e.g. Element.animateTo.
> (4) Rework this interface so that the fill mode is a separate parameter
> and then at least you don't have to write out 'duration' every time.
> Any thoughts?
> Thanks,
> Brian

Received on Tuesday, 6 August 2013 01:38:05 UTC