| • bzimport | |
| May 5 2005, 11:13 AM |
| F2002: IEPNGFix.patch | |
| Nov 21 2014, 8:27 PM |
Author: lowzl
Description:
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.
Version: unspecified
Severity: enhancement
Platform: PC
URL: http://homepage.ntlworld.com/bobosola/index.htm
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Declined | None | T4074 PNG transparency fixes for IE users | |||
| Invalid | None | T20470 Incorrect semantics for PNG images on IE 6 |
lowzl wrote:
Proposed patch
Most of the code was originally adapted from IEFixes.js by Chris Fritz
(meowth346@filb.de).
Explanation:
is so that all skins are affected by the fix, not just Monobook or Standard,
etc.)
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.
Attached:
dbenbenn wrote:
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?
dbenbenn wrote:
[[: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.
lowzl wrote:
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.
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...
ayg wrote:
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.
ayg wrote:
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.
kliu wrote:
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.
ayg wrote:
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.
ayg wrote:
(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.
ayg wrote:
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.
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.