A

B

PNG alpha transparency: AlphaImageLoader filter flaws

filter: progid:DXImageTransform.Microsoft.AlphaImageLoader

This MS proprietary alpha image loader filter is often used to work around the missing 32-bit PNG alpha transparency (24-bit + 8-bit alpha channel) support in IE6/Win. The AlphaImageLoader filter is a “procedural surface”, it displays an image “between the object background and content” [Visual Filters and Transitions Reference]

The new PNG capabilities of IE7 aroused appetite and some moist hands. But as a matter of fact, we'll see more and more of this filter stuff to bring IE6 on a par with IE7.

Problem: Links don't work

Links placed above an element with a filter attached may not work. There are two settings with different solutions:

The filter is applied to an element with a static position. Here, the links problem can be solved by adding a {position: relative; }, maybe combined with z-index [Cross-browser semi-transparent backgrounds, comments section].

The filter is applied to an absolutely or relatively positioned element. The links are not clickable when placed above a region where the transparency is not full (see test A, orange area). The position: relative / z-index-hack does not work in this situation, and the solution requires a markup change, see the following workaround and general steps.

Workaround for “positioned filters”

The workaround I am presenting requires an additional inner wrapper to the positioned element without any logical inherent explanation.

I had to move the filter from this absolute positioned element to a non-positioned child (which has "layout", e.g. by applying a dimension) to get the links to work, in this case, the ul (see test B). Of course, alternatively, we could build two independent absolutely positioned containers, one for the image, one for the links, and overlay them.

General steps to fix this bug

You have an absolutely or relatively positioned box with a filter patched on it. This box contains links that don't work.

The computed dimensions of the #posbox can be determined by a given width/height or by its content. If it has a given width/height, apply width: 100%; and/or height: 100%; to #innerwrap – eventually, this may require paddings to be moved. Otherwise, if the computed dimensions are just determined by the content of #posbox, apply zoom: 1; to #innerwrap. Learn about hasLayout.

Technical notes on this example

The multiple classes are used solely to illustrate the problem in test A vs. B.

The link underlines are used solely to indicate that the mouse event depends on the transparency of the pixel below the link.

I think it's not a z-index-related problem because I can give the links their own background, which can be seen above the transparent png, but the non-transparent regions still won't work.

Problem: The filter does not apply at all

Lots of reasons for this. Check for a starter:

A filter does solely apply to elements that have “layout”. See our article for a list of properties that let an element gain haslayout.

You have multiple “standalone” versions of IE installed, say IE7 side-by-side IE6. The Conditional Comment may not work as intended because the version vector of such a combo is normally the version of the newest browser, i.e. 7.xxxx, therefore, [if lt IE 7] does not match for IE6's parser in this constellation. A workaround might be to hack the registry. The latest version of Multiple IE counteracts these problems, respects the version vector and displays the alpha PNG filter as intended [Install multiple versions of IE on your PC].

You are using a Conditional Comment with the wrong syntax: Note that required blank between “IE” and “6”.

The sophisticated .htc behavior file you have copied seems to fail, but in fact your server is misconfigured. As of Windows XP SP2, a .htc-file must be served with the MIME type of text/x-component. When you can see the source of the .htc when browsed in Opera, because it is served as text/plain, something is probably (but not always) wrong. Check the documentation for the .htc-file for more information.

You mean IE5/Mac? IE5/Mac does provide PNG transparency, but not this filter stuff. Authors who don't use Conditional Comments, but the Star html hack instead, should be aware of the problem that * html .filtered {background-image: none; filter: ...} does apply to IE5/Mac too. Use at least the correct “hide from IEMac / Holly Hack” type of hack, and don't mess around with things you haven't read about: /*\*/ * html .filtered {...} /**/

The filter does not apply to IE5/Win. Serve a transparent GIF instead.

Be sure to test the path to your image in a ten-liner test page before posting a 1.000Kb listing to the next forum.

Problem: background-position, background-repeat, background-attachment do not work

Yes. A filter is not a background image. You cannot tile or position the image displayed by this procedural surface. You might stretch the image by setting the filter's sizingMethod property to scale.

Problem: filter won't validate

Of course not. It's a proprietary extension of Microsoft. Place it inside an external style sheet for IE-hacks, and link to it from within Conditional Comments. This does not make it valid, but the validator cannot see it anymore.

Script resources

These scripts conveniently apply the AlphaImageLoader filter, with its drawbacks, that is.

Alternatives

I wonder if authors have attempted a similar effect with a 100% transparent single color of an indexed palette in PNG/GIF. Many help forum questions regarding the filter arise out of a situation where only a full transparency would be needed.

An alternative may be a special PNG8 format, supported by Adobe Fireworks. The 4-bit alpha channel shows a semitransparency in modern bowsers and degrades in IE < 7 [PNG8 - The Clear Winner], so there is no need for a filter or browser hacking. But it depends on the image how graceful such a degradation in IE < 7 really is, as any transparency will become invisible. With my Yin Yang gradient image, the method is not useable.

Example with 8-bit PNG alpha transparency

Notes on this filter concept

Despite of my attempt to answer frequently asked questions, I don't advocate the use of this proprietary extension. IE6 does not support 32-bit PNG alpha channel transparency. Filters add to “layout” elements and interact with the event handling. This is a buggy concept. A filter is not a transparent background, it's an element for its own that resides far out off the specs.

Beginners just want to have a nice transparent effect. Often they will end in an IE versioning hackery that is too much for them to handle at that specific point in the learning curve where transparency is interesting. Advanced authors should be experienced enough to design an appealing layout without these filters.

To conclude, I advocate a “degradation without grace”, and I think this is appropriate for IE6. But I don't have many illusions in that regard. As a side note, the next proprietary extension from browser implementators should at least allow for placing its name on one headline.