Slashdot Mirror

There are ways to force IE 5.5 and IE 6 to display a PNG through another image library which does handle alpha transparency correctly. The one I usually use is PNG Behavior, because it's unobtrusive -- the only change it requires is assigning a class to alpha PNGs and adding one proprietary CSS rule.

Basically, it replaces the image with a blank one, then loads a filter which displays the actual image in the background. Since the filter can display alpha transparency, you get an alpha-blended image. This works on native installations of IE 5.5 and IE6. On WINE, though, the filter doesn't work, so all it succeeds in is replacing the image with a blank.

(Oddly, I found the same thing happening to the stand-alone copies of IE on my Windows box when I upgraded from the IE7 release candidate to the final version. It prompted me to finally set up VirtualPC.)

SpellingCow also ripped off WebFX:

http://me.eae.net/archive/2006/09/04/spellingcow/

Check out this link for yourself.

http://me.eae.net/archive/2006/09/04/spellingcow/

It's by the guy who wrote the code which they stole.

These are the worst kind of programmers, if you can even call them that.

Here's an article from James Mc Parlane's Blog that describes the horrible problem with prototype.js and its ilk that define methods in Object.prototype and Array.prototype.

-Don

James Mc Parlane's Blog

Why I Don't Use The prototype.js JavaScript Library

When it comes to JavaScript there is one issue for which there seems to be two polarised camps, and that is the question of extending the inbuilt JavaScript Array and Object types via the prototype object. There are those who do, and those who don't.

I am most definitely one of those in the "Don't, because it 'would be bad'" camp.

Now, thanks to the Web2.0/Ruby On Rails/Nuevo Bubble phenomena there is a widely used library that makes great use of the prototype object and that is Sam Stephenson's prototype.js library.

I ran into an issue 6 months ago and decided I would never ever use prototype.js, despite the fact, and I don't say this often, that after an examination of the code, prototype.js is an inspired work of art.

What I and many many others have discovered is that using the prototype object on the Array and Object inbuilt types increases the chances that your code will conflict with existing or external code. It makes your code not play well with others, so once you start using prototype.js, you have to keep using prototype's paradigm because by extending Array and Object via the prototype object it secretly modifies some of JavaScripts default behavior.

It's the crack cocaine of JavaScript.

This can be a good thing. If you don't want to waste time writing your own JavaScript libraries and learning how everything really works, then using prototype.js and the libraries that extend it (e.g. Open Rico) is a very good way of developing. You will save time and money and all you need to learn is "the way of prototype.js".

Now the entire tasty raisin for the MetaWrap JavaScript libraries is to allow others to easily remix MetaWrap applications via a client side API that can be invoked via XML. The result is that CSS, HTML and JavaScript can be injected into the application, or XML and HTML at any point in the rendering pipeline of the application.

So I simply had to reject prototype.js because, out of the box, the very first time I tried to use it - it snuck out and cut the throat of the JavaScript I was using that relied on performing a for(x in object) on the contents of an Array.

In JavaScript, value types are subdivided into primitives and objects. Objects are entities that have an identity (they are only equal to themselves) and that map primitive properties to other value types, ("slots" in prototype-based programming terminology) - see these testcase #5 - #7. Because of this behavior JavaScript objects are often mistakenly described as associative arrays or hash tables, while functionally they behave like an associative array/hash table, technically this is not their true nature.

Despite this the JavaScript programming world has come to rely on these objects behaving as predictable associative array/hash tables - and prototype.js breaks this.

There is no object more galactically useful than a good associative array/hashtable. There is no problem that can't be solved with a large enough hash table. In highly granular interpreted languages like JavaScript it provides a way to dip into pure native brute force computing power mostly unhindered by the language interpreter.

the little legal action they took increased cross-browser PNG compatibility to the point that people can safely put non-transparent PNG images on their web pages today.

Yeah this is definitely old news (the guys at WebFX were doing this years ago). I don't know why this got posted.
Plus, the author doesn't seem to know what exactly AJAX is:
"AJAX enables advanced features like drag 'n drop, dropdown menus and faster performance capabilities, which are now making their way into Web applications, she said."

Drag 'n drop and dropdown menus have absolutely nothing to do with AJAX. That's just plain old Javascript.

Lots of sites use PNGs with alpha transparentcy in IE5.5+.
Google maps, MSNBC, Virtual Earth to name a few.
See http://webfx.eae.net/dhtml/pngbehavior/pngbehavior .html

It's not tough to figure out what IE does... in fact, there's good documentation and there are even emulation layers available! see here

Maybe some Mozilla proponents would like to pretend that it's a pure w3c implementation, but it still has plenty of propriety extensions itself.

However, one strong advantage Mozilla's proprietary stuff has over IE is that it gives you the ability to prototype first-class DOM objects, so you can build an IE-emulation layer for completely cross-platform scripting without a lot of browser-version-checking tangled into your code.

Here's an example of a simple (and incomplete) IE-emulation layer:

http://webfx.eae.net/dhtml/ieemu/

kinda...with the IE specific css filter AlphaImageLoader.

http://webfx.eae.net/dhtml/pngbehavior/pngbehavior .html

Anyway, I admit I did not read the article, but clearly IE already has the capability to blend PNG images into the background. So I wonder what is so difficult about simply making the alphaImageLoader the default behavior for all 24bit png images. I suppose it is the differnce between hacking in the support or making it fit naturally into IE's rendering engine.

Here.

It's a fairly nice solution. Add one .HTC file to your server, and add one style for IMG tags to your style sheet.

IE already dropped support for URLs with an @ in them, and some people accused Microsoft of breaking yet another standard.

Again, you've been able to do this with javascript and html for a long time now:

http://webfx.eae.net/
http://www.bindows.net/

That kind of stuff has been done already for years in plain javascript and HTML:

http://webfx.eae.net/
http://www.bindows.net/

Well, here's an example of where XML is your friend.

Not if you're trying to maintain compatibility with the 94-percenters. XHTML doesn't work in IE. Send XHTML with the proper Content-type: application/xhtml+xml and you get a Save As... dialog box; send XHTML with text/xml and you still don't get access to the HTML DOM.

People have been doing this for years now:

http://www.bindows.net/
http://webfx.eae.net/

See for yourselves.

IE supports the 1-bit transparency in 8-bit indexed PNGs. The problem with this transparency method is that it is the same way GIF uses transparency, which results in ugly jaggies in most cases.

IE does not support the alpha-channel transparency in 32-bit RGBA PNGs without using the fugly proprietary CSS mess that invokes some DirectX stuff to make the transparency work.

I hate the fact that when IE loads my PNGs with alpha it gives it an ugly solid bluish background. You have to hack it just to get my damned images to display correctly in IE. As a result, no one uses regular PNGs.

Well, there is a hack that allows you to have transparent pngs in IE5.5 and up. It uses a filter introduced in ie5.5 to load the aplpha.
There are a few catches though - it needs a 1x1 gif and you need to specify the sizes for the png files.

http://webfx.eae.net/dhtml/pngbehavior/pngbehavior .html

I am using this for my own sites and it worsk well.

Cheers
--Victor

You can also use this hack. if you use the technique described at that site, you only have to add a .htc file to your site, and an entry in your stylesheet to enable proper alpha for .png files, without changing the IMG tags...

Actually, IE5.5+ does have support for PNG alpha-blending. It's hidden in a filter called AlphaImageLoader, and can be enabled through a javascript hack.

Webmasters everywhere take note! You can use cool semitransparent images!

In what way is promoting increased use of PNGs unrealistic?

Well you have to promote them fully. Alpha transparency works fine in IE 5.5+, you just have to know the hack. See this site for a working example.

The method is explained here

PNG transparency works just fine in Internet Explorer. It's just a pain in the ass.

This website will tell you how to turn it on. You can see it working on my website.

No idea why it's not on by default, but if it works...

There's a behavior file (htc) that you can link to on all your webpages that makes IE properly render PNG transparency, if that's what you mean. You can get it here from WebFX.

It is meaningless to comment by saying "hey I use firefox", because the rest of the world is not using it. Now still 25% of my visitors are using IE 5.5, given that IE 6.0 is there 4 years ago.

Yes, it is much easier to make Mozilla/Opera more IE-complaint. [See IE Emu]

It is also quite easy to design a new set of API such that they are deligated to the correct version supported by the browser in runtime. [See DHTMLLib] [See CBE]

But these are just the wrong way.

1. It gives excuses for IE people to think that they are right. It works well for all sites. (but of course we can't afford IE not supported (tm)
2. It makes our code bad. We are not coding for the standard, but for the bad browsers. It created the economics that bad browsers will never be gone.

A patch to IE means:

1. We are coding for the standard. Sooner or later when there is no more IE, just remove the line and our code works pretty well.
2. IE works by emulation. This means it will definately be made slower. When there are enough such sites, it gives people one more sites to move away from IE. That is, IE works, but not as good.
3. IE is considered second class. We focus on standard, and IE just work, by mistake. This is important when IE-to-Mozilla has become 50%-50%. It gives people more comfort to use Mozilla because it has the "brand" to work better.
4. Be prepared that IE can stop working at any time. When IE-to-Mozilla has become 30%-70%, we can start withdrawing this script, forcing extinction of IE.

It is exactly something like Cygwin, which implies UNIX-style programs are correct programs. When you move to Linux is just your choice.

Caveats: You must specify a class, height and width in the img tag. You really should be doing the latter two anyway, so adding a class="png" isn't all that bad.

--
Evan

I wonder if it's possible to implement a DHTML hack for proper PNG support :)

I've used the one available here a few times.

Actually, there is a little-known workaround to get proper png support in IE.
While the workaround is a rather interesting hack, it's a shame there's need for one to begin with.

The hack involves using Behaviors and Direct-X filters. The only drawback is that you can't apply other DX filters on the proper PNGs, but who uses those anyway?

For more info, check http://webfx.eae.net/dhtml/pngbehavior/pngbehavior .html

Internet Explorer can only display RGBA PNG images properly when using an ugly hack that violates CSS specifications and this method is very slow too (noticed when having a page with lots of RGBA PNG images).

If that hack is not applied, Internet Explorer will not show the transparancy, instead it will show either the background colour specified in the image or the browser's default background colour (usually gray), which is fully opaque.

Another issue I have with PNG is that some software seems to generate illegal images. I volunteer at Distributed Proofreaders and every once in a while Mozilla chokes on a page image that's an illegal PNG file. The really irritating thing is that Mozilla is actually able to read the image itself, but if it's allowed to download the very end of the file it says, "This is an illegal PNG! I can't let you look at it anymore!" I have to download the page image and read it with a less intolerant image browser. A pain.

As if that weren't enough, IIS doesn't ship with a metadata entry for PNG. Which, predicably enough, doesn't matter to IE, but screws up more compliant browsers.

Of course, none of the problems are the fault of the PNG people, who have created some very sexy technology. But until PNG images can be displayed reliably, it makes no sense to insist that everybody should migrate away from GIFs.

There's also the little detail that the notorious LZW patent has expired. That removes one of the big motivations for creating the PNG standard in the first place. Yeah, GIFs don't have as many cool features, but they're still adequate for most people's needs.

It's a similar situation with PNG; even though PNG-32 has superior alpha channel support to GIF, you don't see many sites with variable transparency 32-bit PNGs because IE still doesn't support them.

Not to drift too far offtopic, but for what it's worth, there are ways for a webmaster to get proper PNG transparency out of IE5.5+ without too much effort on the part of the web developer. If you don't mind adding some nonstandard CSS (the "behavior" property) to the IMG element, and if you specify a width and height for each image you use, you can use alpha-blended PNGs while still supporting "90% of the users" out there.

In addition, you you can hack some support to MSIE: just use some javascript combined with "behavior" CSS attribute. Can you see the irony of using non-standard feature to fix non-standard behaviour? I have yet to have any luck with this hack combined with absolute positioning, so that isn't perfect. And as far as I know, one cannot use transcludent PNG as a background with MSIE, with hacks or not.

There's also a workaround workaround to make alpha transparency work correctly.

• Bright (download) is the best non-dithering quantiser in the whole world, and reasonably fast, too; based on dlquant
• pngrewrite sorts the palette
• pngcrush removes junk chunks, fixes Photoshop's gamma bug and tries many filters to find a smaller filesize
• OptiPNG is similar to pngcrush, but executes much faster
• pngout uses an alternative deflate, yields sometimes even smaller filesizes
• tweakpng manipulates chunks comfortably with a GUI
• pngquant quantises PNG24 with alpha transparency to PNG8 with transparent palettes, the result is alas mostly ugly

sleightplus demonstrates how to overcome IE's rendering bugs without polluting your markup or styles; no silly style inlining required, either. Use PNG images or backgrounds all the way they were intended.

Predecessors with only support for foreground images: Youngpup sleight, WebFX PNG behavior, mongus pngInfo, Bob Osola. PNGHack, a server side solution, is doomed to fail because of dysfunctional browser sniffing.

If that was useful for you, and you are a C hacker, I have a plea. Take the dlquant sourcecode (see above) and massage it so it works with PNG instead of the archaic PPM. I want a functional Bright clone for Linux that takes a true colour PNG and outputs a paletted PNG. Can you do that?

it is indeed possible to get alpha transparency in png, one description of how to do it can be found here.

Ah yes, cheers.

This was actually what I was refering to when I (seemingly incorrectly) said 'VB hack'.

Example: http://webfx.eae.net/dhtml/pngbehavior/pngbehavior .html

24-bit PNG:s with transparency are great. It definitely fills a purpose, but for some reasons it has not become widely used.
Let's say you create an image with a shadow, using 24-bit PNG:s you don't have to think about what background it will be used on. The whole color range of the site can be changed without having to change any images, just by loading another style sheet.

Unfortunately IE doesn't support 24-bit PNG:s and transparency as it should, but you can make it work using this hack.

Try doing transparency with png's in IE. They sort of support png but transparency was clearly too much for the IE programmers. That's why everybody still uses transparent gifs

Actually it's quite simple provided a client uses IE5.5 or higher.
I suggest reading a workaround to get transparent PNG's to work under IE.

Developers have to work around different OS versions, OS's, etc all the time. It's not that much work to code against IE on Windows - afer all web developers coding against W3C standards do it all the time!

You can actually display alpha layered PNGs on Microsoft Internet Explorer, starting from version 5.5, using an ugly workaround using DirectX and a CSS3 directive.

Now, be prepared: it will work _only_ with tags, so no alpha for background images yet. Still, it's an improvement.

I still don't get why they didn't implement it properly in the first place, let's not talk about it, it's a 1996 recommendation and I'm already so mad and frustrated by their bogus workarounds covering their flaws (XML parser bugs, ignores the IGNORE directive in DTDs, anyone?)

Anyway, the trick is to use a CSS on all images:

img { behaviour: url('/path/to/.htc'); }

using the .htc file coming from here:
Thanks

You just have to point to a 1x1 spacer GIF in the .htc source.

Works pretty fine, is compatible with Opera/Mozilla/IE and _at last_ you can get rid of 1988-oriented GIFs.

Should you want to support IE 5.5, welcome to the future of the web of yesterday :)

1. MSIE does fine with non-transparent PNGs, at least on my computer.

IE can't use PNGs for non-rectangular images...what can it use? GIFs...so we're back to GIFs.

OK -- I take it back. Here's how to do alpha channel PNGs with IE 5.5 and above.

The method is UGLY, as the author of the code points out; "Actually, IE does have PNG alpha transparency, but it does it in an IE specific way. It sucks that it has to be done that way, but it does work, I have done proof of concept on it in the past."

sigh .. You ask Microsoft and they'll say yes. Meanwhile in the real world, no they don't.

It can handle gif-like transparency (single colour transparency) normally. But to support 8 bit alpha level transparency, you have to use a script to 'make it' do it. Here's some example links:

Discussion and howto from evolt.org

WebFX's script

Petition to Make IE support PNG properly (as if MS would ever listen .. grumble

Standards compliance is an issue not only concerning banks. Today the div shows up in the wrong place, tomorrow I'll only be able to access my bank account with M$ OS.

Mozillableness:
bad example: Globes IL

good example: WebFX

B.t.w, my bank's website works well under mozilla

More on the PNG behaviour
Mozilla's XBL, like behaviours

More on the PNG behaviour
Mozilla's XBL, like behaviours

The wrapup of how all browsers do at supporting PNG
A demo of transparent pngs that works in ie for windows

Well, there's one IE emulation script here that I know of. It's a regular .JS script, designed more for designers to adapt scripts easily than for clients, but it shows off the advanced side of Moz's JS 1.5 support (getters/setters for properties...).

This brings up one of my older thoughts: you know how we can format sites with user-defined stylesheets, how about user-defined .JS files added to each page you load (without a local proxy)? Is it possible to add DOM properties with the user prefs JS files somehow? This could be very useful -- emulate IE, any other browser, customise the behaviour of any document function...

Found this via the demos on the Mozilla 1.0 start page. Enjoy.

One fo the best things about Mozilla, from a DHTML web developer's view like myself, is its excellent JavaScript support.

One of the best features is that every HTML element in the DOM, such as 'document' and 'select' and all the other objects you can implement, has a real-time modifiable JavaScript prototype/class. That means you can add properties, methods, etc. to eny and every object.

For instance, now you can actually say things like "I wish they included a .highlight() method for every button on the page", and do it with a few lines fo code.

The upshot of this is that Mozilla is very extensible. I seriously urge everyone to check out this site which offers an Internet Explorer emulation library for Mozilla. It's interesting, to say the least, as it emulates a decent portion of the IE DOM in JavaScript.