Bug Tracker

Opened 13 years ago

Closed 12 years ago

#6325 closed bug (invalid)

setting .css for class destroys its :hover definition in css file

Reported by: mrfx Owned by:
Priority: low Milestone: 1.4.3
Component: css Version: 1.4.2
Keywords: css :hover hover Cc: [email protected]
Blocked by: Blocking:


First let's define in styles:

.classOne { background-color: white; }

.classOne:hover { background-color: green; }

Afer use of:


classOne elements will change to red, but green hover color will not work anymore.

Change History (3)

comment:1 Changed 13 years ago by dmethvin

Most likely because the .css() is done with an inline style? A workaround would be to change the class instead.

comment:2 Changed 12 years ago by addyosmani

Priority: low

What appears to be happening here (as tested in FF 3.6.10 and Safari 5.02 on OSX) is that setting the css for a class definition results in that change effectively resetting the attribute you were updating for other events/states defined for that class such as :hover.

Please see here for a live example: http://jsfiddle.net/UqmCw/

Eg. if I have a class-name of type .myClass and a hover state .myClass:hover, both of which had different background-colors, setting the background-color of .myClass through jQuery (in terms of what FireBug is seeing at least) is resetting the values of that attribute for .myClass and .myClass:hover and then applying the updated background-color attribute as per what was being set in jQuery.

This *may* be desired functionality or it may simply be a case that as we don't support selecting via :hover (this is an event, not an attribute), updating the value of a class *does* result in a reset on all states but we simply don't have the ability or support for updating :hover back to it's original value.

Flagging for review as a better explanation for this may be available.

comment:3 Changed 12 years ago by snover

Resolution: invalid
Status: newclosed

This is how CSS specificity works.

Note: See TracTickets for help on using tickets.