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

On 2015/03/12 10:54, Shane Stephens wrote:
> On Thu, Mar 12, 2015 at 12:38 PM Brian Birtles <bbirtles@mozilla.com
>      > 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?

Yes.

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

Ok, that makes sense.

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

Yes.

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

We want to be able to inspect the keyframes for a CSS animation so we 
need something here. Perhaps even a reference to the CSSKeyframesRule 
(on a suitable CSSAnimationsKeyframeEffect subclass) might suffice as a 
bare minimum.

I think we can probably do better but I'm not sure exactly how it should 
look yet.

Seeing as this is an existing limitation in the spec and we agree on the 
direction we want to go, I don't think it should block the proposed API 
changes so I've gone ahead and merged them now.

Best regards,

Brian

Received on Friday, 13 March 2015 07:08:19 UTC