Re: [web-animations] Significant changes to Web Animations coming up

On Thu, Mar 12, 2015 at 12:38 PM Brian Birtles <> wrote:

> On 2015/03/12 10:10, Shane Stephens wrote:
> >
> >     Unfortunately I was unable to make a shared keyframe list since as
> was
> >     discussed at one stage.[3] This is because keyframe lists return
> their
> >     computed offsets but for paced keyframe lists, the computed offset
> may
> >     depend on their target element in order to resolve percentage values,
> >     for example. This is problem exists with the API regardless of this
> >     change so we can address it subsequently (e.g. by making the computed
> >     keyframe list getter take a target element).
> >
> >
> > I am very concerned by this.
> >
> > Our implementation demonstrates that parsing of keyframe lists is a
> > major cost, possibly the largest cost involved in setting up animations.
> > Sharing keyframe lists where possible would be a major benefit.
> Out of curiousity, what part of this is expensive?

Parsing CSS property names and values.

> > Furthermore, keyframe lists should only deal with specified lists - the
> > problem you're describing doesn't need to exist as accessors on a
> > KeyframeList should return the unmodified inputs.
> I tend to agree, but that's not what's specced now (i.e. before the
> change I'm proposing). We already return the computed list so we already
> can't share KeyframeEffect objects.

True. Seems like we're both happy to make this change though?

> > It's fine to keep a getFrames method on the KeyframeEffect object for
> > accessing the computed result (in a place where the target is known) -
> > although I think this could be deferred to a later level as we don't
> > have currently have strong use cases for it.
> I thought you had a strong use case for it? That seems to be why we
> added it.[1]

That predates the normalization simplification that we introduced a few
months back. The rules for normalization are now much easier to duplicate -
basically, you're guaranteed that the offsets will be sorted and just need
to duplicate distribution.

> It sounds like we could have KeyframeEffect.frames return an iterable
> KeyframeList object .and take a union of (Keyframe or sequence<Keyframe>
> or KeyframeList) on setting.
> The we could add KeyframeEffect.getComputedKeyframes() if/when needed
> for getting the copy with offsets filled in.

That works for me. Would we also have a KeyframeList constructor?

> At first I thought the KeyframeList object would be something like:
> interface KeyframeList {
>    readonly attribute unsigned long length;
>    iterable<Keyframe>;
> };
> Then you could do:
>    effectA.frames = effectB.frames; // Share the list of frames
> Unfortunately, this approach seems to break down.
> Firstly, if we add indexed property getters (as we probably should),
> you'd get authors doing the following:
>    effectA.frames[2].offset = 0.5;
> and then being surprised that it doesn't work (since Keyframe is a
> dictionary object, not a live object).

Yep, that's a good point.

> Also, if you actually want to get a copy (so you can make some
> modifications that only apply to one keyframe effect), I'm not sure how
> you'd do that short of defining our own clone() method on the interface.

list.clone() seems reasonable.

> Maybe we'd need another interface member that returns a sequence?

> Any ideas?

We could optionally start with opaque and immutable KeyframeList objects -
i.e. not observable or modifiable after construction - and add affordances
to get at/change the list later if they seem necessary.


> Best regards,
> Brian
> [1],
> item 5

Received on Thursday, 12 March 2015 01:55:23 UTC