Skip to: Navigation | Content | Sidebar | Footer

Weblog Entry

Opacity Bugs

December 12, 2006

Given its relative new-ness of implementation, I hadn’t put the CSS opacity property through its paces yet. I found a situation today where it seemed to fit, and was a little surprised by the results.

Seems that of the three browsers that attempt to support it, only Opera really does it justice. Check out this test page and you’ll see what I mean. Hover the image to see the effects I’m describing:

Firefox 2.0 and Camino
The heading and paragraph appear to be oddly affected by the opacity property, but on hover they restore their proper values. On first glance it appeared they were picking up the image’s opacity value of 0.8 as well, but when I bumped that down to 0.1 they didn’t adjust accordingly. So it seems more like the anti-aliasing level is different between normal and hover states. There’s no logical reason for this, it’s a big old bug, and I suspect somehow related to Gecko’s poor italic handling due to both possibly being the result of poor anti-aliasing handling.
Well, it just plain freaks out. As you move the mouse over the image, it flashes between visible and… not so much. The actual hover opacity value doesn’t even apply. Weird.

Shame. IE7 just gave us PNG opacity, but we’re going to need this one too. I see them as flip sides of the same coin.

Update: Whoops, guess I should clarify, this is OS X only.

Update 2: Check out this revised example. A few commenters pointed out that setting the opacity value to 0.9999 instead of 1 would alleviate the problem, and it did the trick in both browsers. Though not ideal, it seems like a relatively harmless and future-friendly trick to enable opacity today. Yay!

December 12, 16h

Kinda chicken and egg, I guess. We won’t use properties until they’re properly supported. They can’t be properly supported until the initial implementations are tested by us using it.

Glad you’ve helped the ball roll further on this one.

December 12, 16h

Man, just had a look at it in Safari. What the heck is it doing?

It’s almost as it it’s treating the opacity value as a percentage, and compounding the effects every time the mouse moves. Then when it gets to invisible it goes back to 1, or something.


Dave S. says:
December 12, 16h

“Kinda chicken and egg, I guess.”

Yep, same old story. In this case I’m going to go ahead with it anyway, since it’s a minor detail on an obscure page; were it the primary navigation or something important, that would be a little harder to justify.

Still, I’m dreaming of a day where hover changes a nav item from opacity 0.75 to opacity 1. How great would that be?

Riddle says:
December 12, 16h

I couldn’t reproduce that behavior in my Firefox 2.0… I have ClearScreen turned on my XP and in Fx Opera it’s just ok. Is it affecting that test bad or is it slight?

petern says:
December 12, 16h

It seems to work fine in Gran Paradiso Alpha 1


Riddle says:
December 12, 16h

I meant, ClearType.

Joel says:
December 12, 16h

Just for the record, I’m pretty sure it is just browsers that use the Mac version of Gecko that exhibit the anti-aliasing problem. The problem occurs whenever any element is changed from opacity:1 to any other value. A less than ideal workaround is to set the body element (or div#wrapper) to opacity:.9999; in your stylesheet, which makes the “very light anti-aliasing” effect permanent so there is no annoying flash between the two “modes”.
This bug has been biting me all year :(

December 12, 16h

Instead of setting the opacity to 1, try 0.9999. This seems to fix the problem in Safari.

December 12, 16h

Actually it fixes the problem in all browsers. That’s because once opacity other than 1 is assigned, a different rendering mode is used. If you do JavaScript image transitions with opacity, you also need to stop at 0.999 or you’ll see that flash.

December 12, 16h

To be clear, you need to set .info-panel img:hover { opacity: 0.99999; }

Alex says:
December 12, 17h

Just for the record, what Gecko is doing is switching to “Standard” anti-aliasing in OS X, the type of smoothing without subpixel rendering.

You can confirm this by changing your system setting to “Standard,” in which case no change in anti-aliasing occurs.

Alex says:
December 12, 18h

Also… sorry if I’m stating the obvious, but I should probably add that the “opacity: 0.99999” trick will force Firefox and Camino to render everything with “Standard” anti-aliasing, which will be inconsistent with the anti-aliasing used throughout the rest of OS X (unless you’re using Standard to begin with).

Hopefully, this is a bug that will be addressed in the next version of Gecko.

Lyndon L says:
December 12, 21h

I tried to implement opacity (95% if I remember correctly) on some dropdown menus and got some faint ghosting in Firefox (Windows) in the rectangular area that the menus occupy at their largest extent (if that makes sense) when they were in the inactive/mouseout state. I didn’t have time to experiement with it but has anyone come across this and have a solution?

December 13, 09h

I don’t think this problem is only OSX related, I tried on Firefox 2.0 on Windows XP and I can see the exact same problem.

December 13, 09h

Alex is right, Gecko seems to be switching to standard antialiasing. But the culprit with “opacity: 0.99999” is not Gecko. It’s that the underlying graphic library of Mac OS X is unable to draw subpixel antialiasing onto a transparent background which has to be used to draw the element prior changing its opacity. And it’s not even the fault of the graphic library, but rather it’s the fault of the underlying image format (aRGB) which does not support independent alpha channels for each of the subpixels. That’s likely to be a problem for a long time, although in clase Dave’s example it could probably be arranged in Gecko by not overusing off-screen image buffers to draw the page.

I wrote about this last February, althoug it was not really about a web browsers at that time:

Here are some general tips to keep subpixel antialiasing working on web pages: if you specify opacity, also specify an opaque background on the same element or on the child elements containing text, or if you’re just playing on the text opacity, use a transparent text color: “color: rgba(0,0,0,0.5)”. Note that these tips only deal with the theorical limitations of rendering with aRGB, not browser bugs.

Paulo Elias says:
December 13, 12h

On a related note… Be careful when using IE’s special filters to get opacity in navigation elements. I tried to set the background opacity in a recent Son of Suckerfish menu nav system and spent close to 3 hours trying to figure out why the 3rd + level menus were not rendering. The initial dropdown showed fine with the transparent BG but the sublevel menu did not render at all. I thought I came across some weird IE clipping problem but it turns out it was not the CSS at all. To make a long story short once I commented out the IE filters it all worked fine. D’oh!

Same goes for transparent PNG’s in navigation. This past spring I had to use Cederholm’s Accessible Image-Tab Rollovers[1] to develop the main nav in some web site templates. Sure enough, after a few hours of pulling my hair out trying to figure out why IE was chocking, it had to do with the special filters you need to use to get transparency in PNG’s to work correctly. I got rid of the filters and used gifs instead.


Ville says:
December 14, 15h

So even in the revised example Gecko/Mac OS X still renders the text a bit lighter than in other browsers due to the set opacity for the image? This is a really annoying bug because with certain backgrounds (and text color) the text can become almost unreadable.

December 15, 09h

Ville: in the revised example, the text will render with subpixel antialiasing disabled; the text may be “lighter” in Gecko, but only for those with subpixel antiasing turned on. For those with subpixel antialiasing turned off, the text will always be “lighter” whatever the browser. So you should never chose a color scheme that makes the text unreadable under those conditions anyway.

dusoft says:
December 16, 05h

Works OK in Firefox in Linux.

December 17, 06h

I noticed this a while ago and thought it might help with the over anti-aliasing problem in Firefox / Mac OS X:

December 18, 23h

Yeah, I use divid.onmouseover=new Effect.Appear(‘divid’,{from:0.0,to:1.0}) and it works everytime, every browser.

Firefox text still changes a little. But they are working on fixing it, if it already hasn’t been fixed.


December 20, 05h


I like it :)

January 09, 08h

Same as on with the upper top navigation and the upper heading (when covered with parts of the drop-down menu). I wait for a fix or a solution.

Scott Turnbull says:
February 03, 18h

I discovered a problem with opacity today. Each time I included an opacity property the overall webpage responsiveness decreased. At first I was miffed as to what was causing the problem. But when I commented out all the opacity references, the page responsiveness reverted to normal. Any more than two references and you have problems. I was using Safari, and firefox for OSX. So I don’t know if this is true for all browsers.

March 27, 02h

I’d really like to use Opacity on my site. Is the 0.9999 workaround really fixing the problem for all browsers??? Also for IE7 ??? I can’t test that because I don’t want to lose my IE6 installation…. :-0 ?!! Thanks! Heidi :-)

Daniel says:
April 14, 03h

to test your website in various versions of the MS Internet Explorer you can use MultipleIEs. . So you can take a look at your site in IE 3.0 - IE 6.0 without losing your current version.