According to this post on the YUI Blog by Stoyan Stefanov, both AlphaImageLoader (used to make alpha transparencies in PNG images display properly in IE6) and the alpha filter (IE's equivalent of the CSS3 opacity property, used to create partially transparent elements in IE/Win) use a lot of memory and can be a significant negative impact on browser performance in IE. The former even can make the browser completely unresponsive while they are processed sequentially. So what can one do about this, you may ask?

As Stoyan says, one solution is to use VML (Microsoft's proprietary solution for vector graphics). Apparently while IE6 doesn't properly support alpha transparencies normally, it does when the PNG image is used on a VML element. The tests Stoyan performed show that it runs about 10 times faster and uses about one-tenth of the memory — now that's a significant performance improvement!

So how does one use VML? Well lately, I've been using the script DD_belatedPNG by Drew Diller (which Jonathan Snook happens to mention in the comments for the YUI Blog entry). I switched to it because it supports using background-position and background-repeat, which AlphaImageLoader can't do. I'm pleased to find out that it apparently has a performance improvement as well over scripts such as Supersleight and Unit PNG Fix, which use AlphaImageLoader. Here's another script to automatically generate the VML elements in IE6. And of course, if someone really wanted to, one could statically embed the VML elements in the page's markup within a conditional comment to hide them from browsers that don't need (or even support) them.

I also mentioned the alpha filter. According to the YUI Blog entry, alpha filters also use a lot of memory, so I suggest you avoid them when you can and use VML and a PNG instead. When you can't avoid the use of the alpha filter, however, you might need to use AlphaImageLoader as well, to avoid the ugly rendering of alpha transparency in PNGs when the alpha filter is applied to it (which is a known limitation in IE7-8).

I hope you've enjoyed this second post on improving how you use PNG images for cross-browser compatibility and speed optimization.

Lately web page total size optimization strategies and how to make pages degrade gracefully in IE6 have been on my mind. Recently I've started using a few great programs for optimizing PNG files. Among other things, they can in many cases (depending on the number of colors used in the image and the number of opacity levels) convert PNG-24 format images with alpha-transparency to PNG-8 format with alpha-transparency — a feature that PhotoShop doesn't support (but Fireworks does). The program that actually does that is called pngout. It's a command line utility though, so I've been using PNGGauntlet and PNG Monster which are also free and provide a GUI to use pngout (and in the case of PNG Monster, other PNG optimizer utilites as well). I like PNGGauntlet's interface better, but in some cases it outputs files that are larger than the originals, which is not helpful. Also, probably due to it being a .Net app, PNGGauntlet is rather slow to start up.

Besides the smaller file size, another benefit of using images in PNG-8 format with alpha-transparency is that IE6 will render regions with alpha-transparency as fully transparent instead of the ugly grey that it shows by default with PNG-24 images that use alpha-transparency. Watch out for greyscale PNGs though. Just like with PNG-24s, IE6 doesn't natively support transparency in greyscale PNGs either. I've been using TweakPNG to remove unnecessary data chunks (e.g. file creation date) from PNGs for a while, and it's also great for seeing which format a PNG image is actually using.

If you want a tool that will convert a PNG-24 with alpha-transparency to PNG-8 when pngout won't, then check out pngquant, especially the improved version of pngquant by Kornel Lesinski

These tools have been available for a while (it seems both pngout and pngquant were first publicly available in 2002), but don't seem to have gotten the attention they deserve. Look for a future blog entry on partial transparency in IE.

Related Articles

• PNG8 - The Clear Winner
• Making "IE6-friendly" PNG8 Images
• One PNG, two browsers, no hacks
• Clever PNG Optimization Techniques

Webkit browsers (which include Apple Safari and Google Chrome) and Konqueror make an absolutely positioned element be positioned below an inline element sometimes, as if the inline element was a block element. That happens when the absolutely positioned element is automatically positioned, has display:inline, and follows the inline element which takes up the full width (or almost the full width) of the parent element. Take a look at the following five examples. (To be clear, it's the third and fourth examples that are displayed differently in Webkit browsers.) Then we'll take a look at some solutions.

Examples

Normal Inline Element

Image Element

this is an absolutely positioned element that's positioned automatically

Full Width Image Element

this is an absolutely positioned element that's positioned automatically

Full Width Inline-Block Element

Block Element

Solutions

Some ways to get browsers to handle this more consistently are to give the sibling inline element display:block (like in the 5th example), float:left, or float:right. However, the float fix doesn't work correctly in Opera, Konqueror (tested in 3.5), and Safari 1.0 (I have access to neither 1.2 nor 1.3 currently, but it does work in Safari 2+). Alternatively, one could give the absolutely positioned element display:block, but IE5-7 won't render that differently so it's not the best for cross-browser consistency. Lastly, one could, of course, specify explicitly where the absolutely positioned element should be positioned (with the top and left properties, for instance), which often entails giving an ancestor (which could be the parent, of course) position:relative to create a new positioning context. So, to summarize, the first (shown above) and fourth/last fixes are best for cross-browser compatibility.

Floated Image Element

this is an absolutely positioned element that's positioned automatically

Block Alternative

this is an absolutely positioned element that's positioned automatically and has display:block

Explicitly Positioned

this is an absolutely positioned element that's explicitly positioned

So it's interesting that in this one area at least a few versions of each of 3 of the 4 major rendering engines have a bug. (Webkit was originally based on the KHTML engine used in Konqueror, so while not exactly the same, they often have the same CSS bugs.) And in case you're interested, here's the relevant section of the CSS2.1 specs.

In IE5.5-7, an element that has "hasLayout" and has a bottom margin will sometimes wrongly collapse its bottom margin through the bottom edge of its parent (but not its parent's parent). This happens when its parent has bottom padding and/or a bottom border (which should prevent the margin from collapsing) but not "hasLayout", and at the same time the parent's parent has bottom padding, a bottom border, and/or "hasLayout".

The solution is simple. Simply trigger "hasLayout" on the parent element or remove the "hasLayout" trigger on the element itself.

In IE5-7/Win when a left floated element immediately follows an absolutely positioned element (whose left and right properties are not set to a value other than the default of "auto") the absolutely positioned element will be shifted to the right by the total width of the left floated element. (Right floated elements don't trigger this bug in left-to-right text mode. As one would expect, in right-to-left text documents, float:right triggers the equivalent bug, but float:left doesn't.)

One solution is to put an element with display:block between them.

Another solution is to add another element there and move either of the existing elements into it.

Last but not least, one could just give one or both of the left and right properties a valid value other than "auto" (or "inherit").