Last modified: 2012-02-22 12:35:16 UTC
Using the DirectX filter workaround (DXImageTransform.Microsoft.AlphaImageLoader), IE users are able to see PNG images with transparency as they are supposed to be. This is already implemented partially for the wiki.png logo.
Created attachment 500 [details] Proposed patch Most of the code was originally adapted from IEFixes.js by Chris Fritz (meowth346@filb.de). Explanation: 1. wikibits.js writes an IE conditional comment into the document body. (This is so that all skins are affected by the fix, not just Monobook or Standard, etc.) 2. IEPNGFix.js hooks fiximages() to the onreadystatechange event. 3. fiximages() invokes fiximage() on each image element. 4. fiximage() converts the image to use the DirectX filter. Notes: blankSrc in IEPNGFix.js is set to "/w/skins/common/images/blank.gif". This image must exist and should be a 1x1 transparent GIF.
I had to give up on [[Template:Chess position t]] because of this IE bug. You say "This is already implemented partially for the wiki.png logo." So is it possible to produce transparent PNGs that work on IE (without this patch having been applied)? How?
The patch extends the technique used to make the logo PNG transparent.
[[:Image:Wiki.png]] apparently does not have transparency working in IE6, as can be seen on the 25 pixel thumbnail of the logo at [[Template talk:Chess position t]]. Perhaps you are referring to some other image? I'm still curious about this technique that makes transparent PNGs work with Internet Explorer.
That is not what I meant. I specifically meant the logo in the top-left of the Monobook layout. The technique itself is fairly well known - using the DirectX compositor to render on top of a transparent GIF. The patch adds some JavaScript code to do this for all PNG images (or more accurately, IMGs) anywhere on the page. It can be adapted for use in a customised Monobook.js, but it may not be as effective as applying the patch.
*** Bug 7332 has been marked as a duplicate of this bug. ***
IE6 will handle 256 color PNG transparency OK (so the chess template should work OK), but not higher-color ones. Also note that DXImageTransform.Microsoft.AlphaImageLoader does not handle borders very well. For that reason, some javascript is needed. For reference, see [[en:MediaWiki:Common.js/IE60Fixes.js]]. I don't think this can be built into MediaWiki as is...
Marked as Fixed; implemeted in [[en:MediaWiki:Common.js/IE60Fixes.js]].
MediaWiki is not just used on the English Wikipedia. It's used on every other Wikipedia and probably tens of thousands or more of other wikis. Do not mark bugs as fixed unless a fix has been committed to the MediaWiki software, to be deployed to *all* wikis that use it.
This bug has been open for four years and has never been assigned. It is highly unlikely that a *native* solution will ever be implemented, considering the age of IE6. Other projects that want transparency can simply copy the javascript from the English Wikipedia.
If it's concluded that native IE6 PNG transparency support will not be implemented in MediaWiki, which would be reasonable, the bug could be closed WONTFIX. I wouldn't object to that, given its obsolescence (and they tend to have performance issues AFAIK), but I'd like to hear from a couple other developers before WONTFIXing.
As much as I would love to see IE 6 die, the reality is that the uptake of newer browsers has been very slow, and even after all these years, IE 6 still has a significant market share (depending on what website's stats you look at, even larger than Firefox's). This is especially true in corporate environments where IT managers are generally very conservative about software updates and in certain geographic regions such as China (where Firefox has struggled and where high piracy rates coupled with popular locally-brewed browsers like Maxthon have severely hampered the uptake of IE 7 and 8). Since any IE-specific fix can be easily and reliably blocked out with a "conditional comment", it does not add any undue burden to MediaWiki to include an IE-specific fix.
Aren't there noticeable performance implications to trying to apply this filter to all the PNGs on the page?
Yes, there is a performance impact, but it is only noticable when the number of images on a page reaches the hundred.
Update Web browser.
Adding testme. Please test with Internet Explorer 8 and note the result here.
(In reply to comment #16) > Adding testme. Please test with Internet Explorer 8 and note the result here. See bug 234 comment 15.
Recommend this bug be closed as WONTFIX. It is apparrent there will be no native solution available.
I don't think this is high-priority, but at this point I don't think it's WONTFIX either. If someone wants to write and test a patch for this, I'd be okay with seeing it committed. Once IE6 really has such negligible market share that we're not interested in even accepting a patch is when we should mark this WONTFIX.
Fact is, there is no way to fix this server-side, short of converting the image to another format. That leaves client-side javascript, which has it's minor shortcomings, such as handling borders.
*** Bug 6765 has been marked as a duplicate of this bug. ***
Here's another script for handling this via a htc: http://www.twinhelix.com/css/iepngfix/demo/ One thing that might prevent us from applying it to all pngs though: "Due to an IE bug, if you are putting links within an element with a transparent background, the element must not have a CSS relative/absolute position. Otherwise the links will likely be un-clickable."
That basically uses the same technique (the DXTransform filter) as the current javascript on en: does, so it bumps into the same limitations. The en: script handles borders through the use of extra divs, which is not elegant.
Current market share of IE6 as of November 2010 is... 4.1% and dropping fast. (source: http://www.w3schools.com/browsers/browsers_explorer.asp) I am closing this bug. It is obvious a native solution is too complicated due to the filter's limitations; It would have to serve a different HTML structure to IE6 to circumvent these limitation just to handle PNGs, as is apparent with the javascript in use on en.wikipedia.org. This is not worth the effort to build a server-side solution into MediaWiki.
