- From: Sylvain Galineau <galineau@adobe.com>
- Date: Tue, 11 Mar 2014 13:14:31 +0000
- To: "daniel.glazman@disruptive-innovations.com" <daniel.glazman@disruptive-innovations.com>
- CC: "<www-style@w3.org>" <www-style@w3.org>
On Mar 11, 2014, at 3:26 AM, Daniel Glazman <daniel.glazman@disruptive-innovations.com> wrote: > The spec says about CSSKeyframesRule.deleteRule(): > > ...deletes the CSSKeyframeRule with the passed key. > > But the spec explicitely allows multiple keyframe rules for same key, > saying that in that case the last one specified wins. > > Then I assume only the last one specified for a given key is preserved > in the OM. I think it should noted somewhere. Can you elaborate on why? Given the previous sentence I thought you’d expect the last one to be removed, not preserved? > > 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 Good catch. > > 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. > > </Daniel> >
Received on Tuesday, 11 March 2014 13:15:02 UTC