- 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