Bug 25035 - [om] The side-effects of programmatically duplicating a rule key are undefined
[om] The side-effects of programmatically duplicating a rule key are undefined
Status: RESOLVED FIXED
Product: CSS
Classification: Unclassified
Component: Animations
unspecified
All All
: P2 normal
: ---
Assigned To: Sylvain Galineau
public-css-bugzilla
http://lists.w3.org/Archives/Public/w...
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2014-03-12 23:39 UTC by Sylvain Galineau
Modified: 2014-10-31 22:38 UTC (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Sylvain Galineau 2014-03-12 23:39:59 UTC
From Daniel:

"On a similar note, the keyText attribute of CSSKeyframeRule is
read/write. That means it is possible to programmatically assign a
CSSKeyframeRule's key to an existing key in the parent
CSSKeyframesRule... Section 6.2.2 of the spec does not say what happens
in that case and I think it should. In particular, what happens:

- if the assigned keyText is invalid ; should it throw anything?
- if the assigned keyText already exists

Same thing about CSSKeyframeRule.appendRule(). If the key specified by 
the passed string already exists in cssRules, I suppose the existing 
Keyframe should be deleted. This is not specified in the current ED."
Comment 1 Sylvain Galineau 2014-04-01 17:23:53 UTC
Follow up at http://lists.w3.org/Archives/Public/www-style/2014Mar/0517.html
Comment 2 Sylvain Galineau 2014-05-28 21:45:24 UTC
Throw syntax error per WG resolution from 2014-04-02 [1]:

RESOLVED: Keytext on setting invalid value should throw an error.

[1] http://lists.w3.org/Archives/Public/www-style/2014Apr/0016.html
Comment 3 Sylvain Galineau 2014-10-31 22:38:17 UTC
Per WG resolution [1], appendRule always appends a valid rule at the end of the @keyframes rule. The rule's key is not considered.

[1] http://log.csswg.org/irc.w3.org/css/2014-10-27/#e484268