There is no way around the breaking alpha filter except to progmatically limit the size of the element that the filter is to be used on to 2048px high (or for everyone to use Firefox who implement opacity in CSS).

Writing this I have suddenly realised how much I wish M$ IE would just go away as most standards compliant code has to be hacked to work the same in IE!

So if the element you apply the filter to has transparent child-elements, then their transparency will be set to the new value. This is especially nasty if you have for-example a .png with partially transparent edges, as all pixels with opacity greater than 0.0 are set to whatever the new-value is, resulting in jagged-edges.

For example:
pixel’s opacity, opacity: 0.5, filter: alpha(opacity = 50)
75%, 37.5%, 50%
50%, 25%, 50%
25%, 12.5%, 50%

Thanks for your reply. I throught i solved it with my method but i have white pixels again now T_T and reencoding of the picture in any way is not working because those pixels are there whatever i try to do (they are some times here and sometimes there, the location changes but it wont go away). the gif format is the only format where ie does not show the white pixel bug but i cannot save my pics as gif due to color los and therefore ugly gradients.

So, I’d like to be able to have a parent with “opacity: 0.5″ and a child with “opacity: 2″, and have the child finally rendered with 100% opacity. This would be consistent with the fact that, AFAIK, if I specified “opacity: 0.5″ for both of them, the child would end up with 25% opacity.

If I nested the child with “opacity: 2″ inside something with >50% opacity, I would expect it to have 100% opacity as a result: no more, no less.

“The way I see it, if a value > 100% is computed as the total opacity of an element, then surely the value used to compute its colour should be clipped at 100, while the value *inherited by its children* should remain > 100.”

So, the final computed opacity of an element would be limited 0-100%, but it would still be possible to define a relationship whereby a child was more opaque than its parent.

I just confirmed for myself that making a diffuse material colour > 1 in a colour channel in fixed function OpenGL lighting causes ‘more than 100% reflection’. This is calculations in a computer, not physics; conservation of energy need not apply if we don’t wish it to :).

To quote the OpenGL “Red Book”:
“For the versions of glColor*() that accept floating-point data types, the values should *typically* range between 0.0 and 1.0, the minimum and maximum values that can be stored in the framebuffer……

“Neither floating-point nor signed-integer values are clamped to the range [0,1] before updating the current color or current lighting material parameters. After lighting calculations, resulting color values outside the range [0,1] are clamped to the range [0,1] before they are interpolated or written into a color buffer. Even if lighting is disabled, the color components are clamped before rasterization.”
http://www.glprogramming.com/red/chapter04.html

To take a non-hypothetical CSS example: I have a menu which I want to overlay on a header, with opacity. This works and I’m happy with how it looks. I then want to add drop-down menus, but I find that if they have low opacity, they become illegible as they blend with the page content. So I wish to apply >1 opacity so that the drop-downs are more opaque than their parents. Tough, I can’t. Oh well; I’ll have to make another plan.

So, internal values used for calculation can be out of bounds, but the final value used in output is clipped: Let me know if it’s still not clear, or if you think I’m mistaken.

Think logic:
If the object is completely transparent (opacity = 0%) and you can see everything through it as if it wasn’t there, how much clearer could you see through it?
If the object is completely opaque (opacity = 100%), how much more opaque could it be?

Think programatic:
As a web browser, if you have to draw a pixel with opacity = 0%, you don’t display it at all, because it’s completely transparent and you want the user to see whatever was there first (behind it).
If you have to draw a pixel with opacity = 50%, you would make an average of the RGB defining that pixel and the one that was previously there (or usually the white background of the page, if there wasn’t anything) and plot the result.
If you have to draw a pixel with opacity = 100%, you just do it, overwriting whatever was before it.

Blending is done mathematically, something along the lines of:
actualR = newR * opacity + oldR * (1 – opacity)
actualG = newG * opacity + oldG * (1 – opacity)
actualB = newB * opacity + oldB * (1 – opacity)
So you have the old pixel that was at that position defined by (oldR, oldG, oldB), the new pixel (newR, newG, newB) and what you’re actually going to draw on the screen: (actualR, actualG, actualB).
Because of the way the computer screen is designed, every R/G/B pixel has to receive a value, usually between 0 and 255, where 0 = darkest, don’t light at all and 255 = lightest, light at full power. Now, consider that you have a black pixel defined by (0, 0, 0) at a given position and over it you have to draw a white pixel defined by (255, 255, 255) which has opacity 1.5 (that’s 150%). Here’s what you get:
actualR = actualG = actualB = 255 * 1.5 = 382.5
How can you tell that pixel to light up at 382.5 when the brightest it can achieve is 255?

In conclusion, opacity = 0% and opacity = 100% are physical limitations which also have effect in various other ways – logic, programatic and electronic. Any value outside the [0..1] bounds is an error, a fallacy, an illogical result of some bad computations. You are right, DirectX and OpenGL may easily implement their own error-fixing or error-ignoring (not sure about it, but it would be stupid to have something crash because of a tiny overflow of 0.0001) but the fact that you could send your video card a value of 1.5 for opacity doesn’t mean that it makes sense and you always have to think inside those bounds.

Let me know if it’s still not clear.

As Tom has explained, opacity is a scaling factor on alpha. Why this should only be an attenuation and never an amplification is a complete mystery to me. The way I see it, if a value > 100% is computed as the total opacity of an element, then surely the value used to compute its colour should be clipped at 100, while the value inherited by its children should remain > 100.

I’m pretty sure that in OpenGL / DirectX etc, you are able to define values > 1 for a colour channel. If the result of all the lighting / blending / whatever calculations for a given pixel are > 1, then 1 is what gets rasterized.

Oh, how I hate web design… its enough to drive a man to flash ;-) (no idea how that handles similar things, but I bet it’s less idiotic).

i have a similar problem with css opacity in IE. Please have a look at the following site:

http://www.lcdhype.de.vu/stuff/iebug

As you can see, IE displays the picture with random white pixels. Those pixels are not stored in the picture and those pixels are displayed as soon as you add the css filter attribute to the img tag. This is a massive bug and i reported it to m$ already but got no response yet.

All your solutions with zoom, z-index and width won’t work here. My solution: add style=”width:%px” to the img tag where % is the actuall width of the img + 1. You may add a surrounding layer with the actual with of the picture and overflow:hidden when the additional pixel bugs you.

I hope this will help because i have spent so much time figuring this out.