- From: Sylvain Galineau <galineau@adobe.com>
- Date: Mon, 16 Jun 2014 21:16:59 +0000
- To: "<www-style@w3.org>" <www-style@w3.org>
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.
[1] https://www.w3.org/Bugs/Public/show_bug.cgi?id=25035
[2] https://www.w3.org/Bugs/Public/show_bug.cgi?id=25034
[3] https://www.w3.org/Bugs/Public/show_bug.cgi?id=14788
Received on Monday, 16 June 2014 21:17:31 UTC