W3C home > Mailing lists > Public > www-style@w3.org > February 2013

RE: [css3-animations] CSSKeyframesRule.findRule()

From: Sylvain Galineau <sylvaing@microsoft.com>
Date: Fri, 22 Feb 2013 17:59:25 +0000
To: Tab Atkins Jr. <jackalmage@gmail.com>, Daniel Glazman <daniel.glazman@disruptive-innovations.com>
CC: "www-style@w3.org" <www-style@w3.org>
Message-ID: <3C4041FF83E1E04A986B6DC50F0178291BF98147@TK5EX14MBXC223.redmond.corp.microsoft.com>
[Tab Atkins Jr.:]
> 
> On Fri, Feb 22, 2013 at 6:48 AM, Daniel Glazman
> <daniel.glazman@disruptive-innovations.com> wrote:
> > We discussed findRule() during this week's conf call.
> > I guess the proposal is to change it from
> >
> >   CSSKeyframeRule findRule(in DOMString key);
> >
> > to
> >
> >   sequence<CSSKeyframeRule> findRules(in DOMString key);
> >
> > of course, the |key| here is subject to the change proposal made
> > earlier by Sylvain.
> 
> This doesn't go far enough.  The current IDL *doesn't make any sense*.
>  Keyframe selectors use <percentage> tokens or from/to keywords, but the
> method takes a <string> containing a number between 0 and 1.

Only IE implements the spec here. WebKit and Gecko take a percentage string.
I think we should follow the latter. 

Given our decision to allow keyframe rules to cascade I think having a 
findRules (plural) method is fine. Ideally it could take the keyText value
from any given CSSKeyframeRule object and return all the rules for it.

As suggested in my response to Daniel we would then use findRule to return
the cascaded/resolved rule for a single keyframe selector value.

> There is *never* a "rule with a key matching the passed key".  It also
> doesn't talk at all about what to do with a keyframe rule with a list of
> selectors.
> 
> I suggest changing this to take a string containing a percentage, and then
> define that it returns any rules with that percentage in their selector
> list.
> 
That works too, if we can prove to ourselves the compat impact is low enough
to break it. 

Received on Friday, 22 February 2013 18:00:14 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:21:06 GMT