Last modified: 2009-04-17 11:30:24 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 18470 - Incorrect semantics for PNG images on IE 6
Incorrect semantics for PNG images on IE 6
Status: RESOLVED INVALID
Product: MediaWiki
Classification: Unclassified
Parser (Other open bugs)
unspecified
PC Windows XP
: Normal minor (vote)
: ---
Assigned To: Nobody - You can work on this!
http://code.kliu.org/misc/fixiepng/
:
Depends on:
Blocks: 2074
  Show dependency treegraph
 
Reported: 2009-04-15 02:23 UTC by Kai Liu
Modified: 2009-04-17 11:30 UTC (History)
3 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments
simple fix (1.22 KB, patch)
2009-04-15 02:23 UTC, Kai Liu
Details

Description Kai Liu 2009-04-15 02:23:22 UTC
Created attachment 6028 [details]
simple fix

The current IE 6 PNG alpha channel fixup method (see [[en:MediaWiki:Common.js/IE60Fixes.js]] and bug 2074) is flawed because it replaces original image element with a new span element that calls up the alpha loader.

The problem with this approach is that a span is semantically different than an image, and this means that parts of the browser UI--most noticeably the right-click context menu and copying-and-pasting a selection that contains an image--are broken by this.  Of course, if it was a choice between having alpha-blended images display properly or having the correct semantics, I would choose the former, but it is possible to "have your cake and eat it too".

Only a few minor changes to the existing code are needed to do this.

1) The original image element should not be removed; instead, the span should be inserted with the "position: absolute" style right before the image element as a sibling; this will ensure that the span element will be positioned in the exact same location as the original image (the two elements will now occupy the same space).

2) The span element's z-index should be set lower than the image's, so that the span will appear underneath the image for purposes of user interaction.  This ensures that if the user tries to interact with the image, the user will get the image itself and not the fixup span.

3) Since the original image must be kept in the document tree in order to preserve semantics, there has to be another way to hide it: by using the opacity filter.

4) Since the user would be interacting with the original image element, it would no longer be necessary to manually set the hand cursor for linked images, so that particular hack can be removed.

With these simple changes to the existing code (see attached patch), you can fix the IE 6 problem without breaking the semantics or the browser UI.

A demonstration of this can be found here:
http://code.kliu.org/misc/fixiepng/demo.html

Note that, in this demo, right-clicking the image allows you to save/print/e-mail the image, and it is possible to include the image in a selection.
Comment 1 Erwin Dokter 2009-04-16 10:16:54 UTC
Since this script is not part of the MediaWiki software, I am marking this as invalid. But I invite you to post the fix for discussion and testing on [[en:MediaWiki_talk:Common.js/IE60Fixes.js]].
Comment 2 Kai Liu 2009-04-16 11:29:46 UTC
(In reply to comment #1)
> Since this script is not part of the MediaWiki software, I am marking this as
> invalid.
> 

In bug 2074 comment 8, you marked that bug as fixed, saying that it was "implemented" in this particular file, which seems to contradict the statement that you just made in this bug.  Could you please clarify what the status of IE60Fixes.js is?
Comment 3 David Göthberg 2009-04-16 12:29:05 UTC
Kai Liu: I think Erwin is kind of correct. He pointed you to the right talk page. The [[en:MediaWiki:Common.js/IE60Fixes.js]] file is loaded from [[en:MediaWiki:Common.js]]. Both are files local to the English Wikipedia and can be edited by admins on the English Wikipedia. Unfortunately this also means that any fixes applied in IE60Fixes.js will only benefit the English Wikipedia. 

So I think that if/when we have used your suggested fix for a time at enwiki and if we feel it works well, then it probably is time to open a bug here and ask to have the fix moved to the global MediaWiki javascript files so it benefits all projects.
Comment 4 Aryeh Gregor (not reading bugmail, please e-mail directly) 2009-04-17 11:30:24 UTC
(In reply to comment #2)
> In bug 2074 comment 8, you marked that bug as fixed, saying that it was
> "implemented" in this particular file, which seems to contradict the statement
> that you just made in this bug.  Could you please clarify what the status of
> IE60Fixes.js is?

[[en:MediaWiki:Common.js/IE60Fixes.js]] is used only on the English Wikipedia (and any other wikis that feel like copying it), and issues with it should be reported on its talk page.  The only relevance it might have to Bugzilla discussions is as a source of ideas or copying.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links