Bug 28617 – Fix CSSKeyframesRule & CSSKeyframeRule types in the IDL

• Status: RESOLVED
• Resolution: CONFIGURATION CHANGED
• Component: CSS

[LEPESME Jean-Baptiste]

Created attachment 38380 [details]
Sample

Found in Chrome 4.0.202.0 (532.0), but same problem with Safari 4.0.3 (531.9.1).

I apologize if i missunderstood something. I searched but found nothing about this.

http://www.w3.org/TR/css3-animations/#dom-interfaces- it' s wrote :
  interface CSSRule {
    ...
    const unsigned short KEYFRAMES_RULE = 7;
    const unsigned short KEYFRAME_RULE = 8;
    ...
  };

And WebKitCSSKeyframesRule and WebKitCSSKeyframeRule seems to have a bad ".type" value.

What is the expected result?
  [object WebKitCSSKeyframesRule].type = 7
  [object WebKitCSSKeyframeRule].type = 8

What happens instead?
  [object WebKitCSSKeyframesRule].type = 8
  [object WebKitCSSKeyframeRule].type = 9

Bye,
Jiboo.

[LEPESME Jean-Baptiste]

Created attachment 38428 [details]
change VARIABLES_RULES to 9, and set the correct value to KEYFRAMES_RULE and KEYFRAME_RULE

[LEPESME Jean-Baptiste]

I made some research and I figured out that the css-variables features of webkit is non "standard" and not intended to be a part of CSS3.

It seems to be based on http://disruptive-innovations.com/zoo/cssvariables/ wich use RuleType number 7.

As css-animations should be in CSS3, i think that webkit had to change VARIABLES_RULES to another value to respect http://www.w3.org/TR/css3-animations/ .

Bye,
Jiboo.

[Simon Fraser (smfr)]

We should really be using values outside the reserved range for features that are not yet in CR.

[Ahmad Saleem]

In attached test case, I get across all browsers (Safari 15.6, Chrome Canary 106 and Firefox Nightly 104) below:

[object CSSKeyframesRule].type = 7
[object CSSKeyframeRule].type = 8

It is expected result as of Comment 0 and I think it was fixed along the way and now this bug can be marked as "RESOLVED CONFIGURATION CHANGED". Thanks!