This is a puzzler for me. I've not run into it before, but for some reason, it's kind of kicking me in the butt on this project. I've got a nav menu, blue background, white letters. No big deal. I've got the the hover state set to reverse that, making blue letters on a white background. Here is the CSS that I am using for the hover state: #navigation A:hover { COLOR: #23698b; BACKGROUND-COLOR: #fffffe; TEXT-DECORATION: none; } Code (markup): The weirdness is that when viewing in IE, the white background doesn't work. The letters turn blue, which makes them disappear into the blue background. If I change the background color to something like #ff0000 or even #fffffe, the hover works fine. It just doesn't seem to like a full white (#ffffff). Yes, it only seems to affect IE. Firefox and Chrome both have no issues with it. Anyone else seen this? Am I losing my mind?
It's on IE8. Haven't tried it on IE7 yet. I've tried toggling compatibility mode off and on several times.
1) switch all that uppercase to lowercase, yes, IE can be THAT picky. There's a REASON you don't see a lot of people writing CSS in caps. 2) are you using JUST the background declaration somewhere else on those anchors? IE often won't override 'background' with just the 'background-' properties. 3) without seeing the markup it's applied to or any other CSS for the page, that little tiny snippet is total gibberish, and we cannot figure out if any other properties would be overriding you. Again, this is yet another "This is why we can't help you"
Wow.. I was skeptical about the uppercase/lowercase thing. But I went ahead and converted everything to lower case, and voila! It is working now. Thanks for the tip, deathshadow. That's a new one on me. I knew IE was a turd, but didn't realize it was that bad! Thanks again!
Well, technically it's 'kind-of' following the specification on that one... but yeah, it is pretty silly to have been the cause. It's also why i always declare my hexadecimal numbers in caps. There are plenty of 'what the' moments like that - see the dissapearing content/double render bug which is actually tripped when comments - YES, I SAID COMMENTS are placed between floats. It's why I comment the close of a section this way: <!-- #content --></div> By putting the comment before the tag, it won't end up between floated elements... then all you have to worry about is Firefux treating comments as block level elements.