854242 - !important declaration overrides CSS @keyframes animation

Status: RESOLVED INVALID

(Core :: CSS Parsing and Computation, defect)

Description

[Louis Lazaris]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:19.0) Gecko/20100101 Firefox/19.0
Build ID: 20130307023931

Steps to reproduce:

Wrote some CSS with !important. Tried to animate those properties using @keyframes CSS animation.

See example here:

http://jsbin.com/ohufah/6/edit

2nd box doesn't animate, but first one does, due to !important added to properties for 2nd box.


Actual results:

The animation does not occur.


Expected results:

I'm not sure. It would seem that Firefox's behaviour is correct, but none of the other browsers I've tested respond this way. They all continue to animate both boxes, regardless.

I've filed a bug report with Chrome here:

https://code.google.com/p/chromium/issues/detail?id=223450

In other words, I'm unsure as to which is the incorrect behaviour. Should !important override an animation on the same properties? Is this similar to the fact that a pseudo-class is overridden by !important? For example:

http://jsbin.com/alenuc/1/edit

Notice the width of the input should increase on focus, but it doesn't because of the !important declaration. I'm not sure if @keyframes should be treated the same way. It would be nice to see all browsers render this the same way, whatever is the correct behaviour.

Comment 1

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

We're still trying to agree on a standard behavior here.  I changed the Firefox behavior intentionally at some point because it seemed like this was the behavior we wanted, though.

Comment 2

[Louis Lazaris]

It looks like this issue has been resolved. Latest Firefox now exhibits same behaviour as Chrome. Should this be marked "resolved"?

Comment 3

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

That sounds odd.  Might you have enabled off main thread compositing and off main thread animations somehow (triggering bug 847287)?

Comment 4

[Louis Lazaris]

Oh ****... My bad... I was looking at the wrong demo. Nevermind, the behaviour is still the same.

Comment 5

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

The working group ended up deciding to go with the current Firefox behavior:
http://dev.w3.org/csswg/css-cascade/#cascade-origin
... which makes this bug invalid, since the current behavior is correct.

Comment 6

[Louis Lazaris]

Cool, thanks for the update. It would be nice if the other browsers addressed this, since their behaviour is therefore incorrect.