Re: [css-animations] Resolving CSSKeyframesRule issues: browser vendor feedback needed

On Mon, Jun 16, 2014 at 2:16 PM, Sylvain Galineau <galineau@adobe.com> wrote:
> We have a number of outstanding open issues against css-animations API e.g.:
>
> - What happens when a keyframe selector is programmatically duplicated [1]
> - What the effect of deleteRule is when there are multiple rules with the same key [2]
> - Whether a comma-separated list of keys can be passed to findRule/deleteRule [3]
>
> I would like to start by clarifying the scope of what the spec should aim for in Level 1.
>
> First, it may help to recall that these APIs read/write the @keyframes rule as specified by the author, not the one resolved and applied by the browser. For instance, if you were to specify:
>
> @keyframes backwards {
>         100% { color: blue; }
>         25% { color: yellow; }
>         0% { color: red; }
>         100% { color:white; }
> }
>
> ...the browser applies the following:
>
> @keyframes backwards {
>         0% { color: red; }
>         25% { color: yellow; }
>         100% { color:white; }
> }
>
> But methods such as CSSKeyframesRule.appendRule or CSSKeyframesRule.deleteRule explicitly run against the former i.e. they update the specified @keyframes, not the computed one.
>
> For Level 1, I assume there is no change; CSSKeyframesRule APIs read/write the specified @keyframes. Updating/adding/removing keyframe rules results in a re-evaluation of the @keyframes rule by the browser.
>
> Second, since this feature is already shipping in browsers we can approach spec fixes using one of three rough approaches:
>
> 1. No change: no new methods, no change of interface; focus on an interoperable definition of each method's behavior.
> 2. Some updates: since keyframe rules now cascade, multiple rules may apply for a given keyframe selector value. We would consider adding a new findRules method to return more than one rule, for instance.
> 3. Redesign: change whatever should be e.g. make CSSKeyframesRule derive from CSSGroupingRule, support real insertRule method with index parameter etc.
>
> Thus far I've assumed we're aiming for #1 in Level 1 of css-animations, postponing the kind of changes we'd make in #2/#3 to Level 2 and beyond.
>
> I'd love to hear from browser vendors before making specific proposals. Maybe you think the call should be made on a bug-by-bug basis; that's fine too.

Where possible and compatible, we should go ahead and make the
necessary changes to make the interfaces sane and consistent with the
rest of the platform.

~TJ

Received on Monday, 16 June 2014 22:48:38 UTC