Jump to content

MediaWiki talk:Common.js/Archive 16

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
< MediaWiki talk:Common.js
This is an old revision of this page, as edited by MiszaBot II (talk | contribs) at 08:08, 29 May 2009 (Archiving 2 thread(s) from MediaWiki talk:Common.js.). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.
Archive 10←Archive 14Archive 15Archive 16Archive 17Archive 18→Archive 20

Namespace tab

Can the hack that caused the "article" tab to display "main page" on the main page be put back in? Maximillion Pegasus (talk) 00:21, 6 January 2009 (UTC)

No. The hack is unacceptable. If this problem is to be resolved, either move the main page to a namespace with a more appropriate tab or edit MediaWiki:Nstab-main to be less specific. See #Main Page tab above. —Remember the dot (talk) 04:52, 6 January 2009 (UTC)

Shuffle for election candidates

The election was months ago, can the "dshuf" code be removed? —Remember the dot (talk) 17:51, 10 January 2009 (UTC)

Oh dear. How did we forget to remove that? Please do so. (Be sure to remember the addOnloadHook bit as well. :-) --MZMcBride (talk) 22:34, 10 January 2009 (UTC)
Done. I also removed the function name "mainPageAppendCompleteListLink" - since the function should only be called once, there is no point in adding overhead by giving it a name. —Remember the dot (talk) 23:07, 10 January 2009 (UTC)

Modernista revisited

I e-mailed Mike Godwin, the Wikimedia Foundation's general legal counsel, asking him what to do about Modernista's trademark infringement. I suggested using JavaScript to blank any page viewed through Modernista, and he replied "I'm ready to resort to any technical measure." So, I'd like to replace the Modernista referrer with the following code: 

if (/modernista\.com/.test(document.referrer)) {
    document.removeChild(document.documentElement)
}

Hopefully that will prompt Modernista to rethink their site. —Remember the dot (talk) 18:11, 10 January 2009 (UTC)

No objection from me. --MZMcBride (talk) 22:26, 10 January 2009 (UTC)
Done. —Remember the dot (talk) 23:08, 10 January 2009 (UTC)
Uhm... what's the problem here, or did I miss something? What they are doing might not be very nice (although I don't really see a problem with it honestly). But does that warrant adding something to the global JavaScript? How many people visit their site anyway? —Ruud 23:52, 11 January 2009 (UTC)
We've had something in the global scripts to react to their site for months now. Previously it just added a warning message, but now we blank the page; it's just a slight escalation, we're not going from scratch. I fully support the idea, and not just because Godwin Said So, although that is a very compelling justification to take action. Happy‑melon 10:20, 12 January 2009 (UTC)
Yeah, but this modernista.com site just a small website, with an original design, drawing maybe 10 vistors a month. Or are they some big, bad, evil, site that is misusing our good name and confusing billions of visitors? —Ruud 16:49, 12 January 2009 (UTC)
The issue is trademark infringement, and I was never a fan of making special JavaScript for them. A legal recourse seems more appropriate to me, but perhaps that's not feasible for one reason or another. —Remember the dot (talk) 02:43, 14 January 2009 (UTC)

"Remove these lines"

Is there any objection to removing these lines from Common.js? 

            Button.style.styleFloat = "right";    //
            Button.style.cssFloat = "right";      // REMOVE THESE LINES
            Button.style.fontWeight = "normal";   // ON 10 FEBRUARY 2008
            Button.style.textAlign = "right";     // 
            Button.style.width = "6em";           //

They seem to have been replaced by 

.collapseButton {         /* 'show'/'hide' buttons created dynamically by the        */
    float: right;         /* CollapsibleTables javascript in [[MediaWiki:Common.js]] */
    font-weight: normal;  /* are styled here so they can be customised.              */
    text-align: right;
    width: 3em;

in MediaWiki:Common.css. —Remember the dot (talk) 19:45, 10 January 2009 (UTC)

The code was added today. I'm pretty sure the 2008 bit is a typo (should be 2009). --MZMcBride (talk) 22:31, 10 January 2009 (UTC)
Ah, I see. That makes more sense. —Remember the dot (talk) 23:10, 10 January 2009 (UTC)
Lol, whoops! I knew I was going to get something (else) wrong in that update. Thanks for the spot. Happy‑melon 10:53, 11 January 2009 (UTC)
Yes, perhaps. I wrote that code and I probably had a good reason for doing it with JS instead of CSS. I think it breaks IE6, but I can't quite remember anymore. —Ruud 23:38, 11 January 2009 (UTC)
Ohw, and the width of the button should really be xem, where x is the number of characters in the caption (including the brackets). —Ruud 23:47, 11 January 2009 (UTC)
That is a misconception; it should match the 6em width of the v·d·e links. — Edokter • Talk • 00:52, 12 January 2009 (UTC)
No, I wrote that code before that v.d.e links stuff ;) So the v.d.e link width should probably match with the width here. —Ruud 01:59, 12 January 2009 (UTC)
It can't; some templates use the long form of 'view·talk·edit' which just fits in 6em. But maybe there should be some mechanism to customize the width of {{tnavbar}}. — Edokter • Talk • 02:38, 12 January 2009 (UTC)
This is discussed above, 6em is massively too wide; what I did in the code I added to Common.css was to make it 3em by default, and add another declaration to override it back to 6em when inside the .navbox class. Isn't that the best solution for everyone? Or are there other instances where it should be 6em? Happy‑melon 10:17, 12 January 2009 (UTC)
I think it needs to be 6em if you're view Wikipedia using a (nearly) monospaced font. Hmm... actually I seem to be using a wrong definition of Em. My main point was, however, that I think using CSS instead of JS is going to break something. —Ruud 16:52, 12 January 2009 (UTC)
[show]
[show]
[edit]
[edit]
3em is definitely too small for me. The text falls outside the box, even the sans-serif one. —Ruud 17:15, 12 January 2009 (UTC)

[edit]

Of course, what we're actually looking for is width:auto;... :D Happy‑melon 18:38, 12 January 2009 (UTC)
Tested on IE6, applying styles via CSS works fine. Happy‑melon 23:35, 12 January 2009 (UTC)

I've restored the code to Common.js. Remember that we still have 30 days decaching time before we can even think about removing the hardcoded styles, so if we find a catastrophic problem before then, well, we should leave how it is now anyway so that people with modern browsers can still style them! If you can remember why you didn't do it with CSS, Ruud, I'd love to hear it, but my suspicion is that you just didn't think of it, which is a perfectly valid reason! Happy‑melon 11:08, 13 January 2009 (UTC)

I've looked through the edits of November 2006 and while there were some problems with styling and IE6 I don't seem to have tried styling it through the CSS sheet. —Ruud 17:49, 13 January 2009 (UTC)

"please use talk for ALL changes"

I find it somewhat amusing that of my three edits yesterday, the one that made no functionality changes whatsoever was the one to be reverted as "reverted code changes". Does anyone have any actual objections to this edit, which merely realigns the comments sections and moves a few braces around? Happy‑melon 11:11, 11 January 2009 (UTC)

Strike that, I see that MZ did actually revert all my changes, as well as the ones in Common.css. I accept that there is a balance to be struck between manintaining code integrity here and not being overly bureaucratic, but my opinion is that this is somewhat on the 'bureaucracy' side of that line, especially as MZ reverted changes both here and at Common.css that were to improve readability while making no functional changes whatsoever. Thoughts? Happy‑melon 12:50, 11 January 2009 (UTC)

Best practices for editing these pages?

I finally took the time to put words on a page vis how I see our Best Practices in editing system messages, particularly the skin files: WP:EI. I don't think we need anything as pretentious as a policy or guideline to control how we work on these files, but it would be nice to have something to point to to ensure we're all reading from the same song sheet. Comments and criticisms would be very welcome. Happy‑melon 23:06, 11 January 2009 (UTC)

Seems reasonable. Just an observation I've made watching these pages: it's quite pointless in making an undiscussed changes as it always gets reverted. 50% of the time because it's a stupid/pointless/annoying/etc. change that probably has been rejected in that past already. 40% of the time because it's essentially a good change but completely breaks some stuff in a totally unexpected ways. And 10% of time because someone else thinks that it should have been discussed first.
And on a more positive side, pretty much all the scipts added have been significantly improved (faster, better compatibilty, more readable, or just better feature-wise) during the discussion by all the JS savvy people hanging around on this talk page. Looking at it pragmatically, discussing something before making a change in article space is almost always going to be a waste of everybody's time, changing something before discussing it on the interface pages is also almost always going to be a waste of everybody's time. —Ruud 23:36, 11 January 2009 (UTC)

Deleting element without confirming that it exists

{{editprotected}} Line 439: 

realTitleBanner.parentNode.removeChild(realTitleBanner)

Should be changed to: 

if(realTitleBanner) realTitleBanner.parentNode.removeChild(realTitleBanner);

This is causing javascript errors because certain templates use realTitle successfully enough but do not add the realTitleBanner element. This causes a javascript error which prevents subsequent scripts from running. — CharlotteWebb 17:22, 16 February 2009 (UTC)

Done. --- RockMFR 18:03, 16 February 2009 (UTC)

Two minor changes

I'd like to make two minor changes here. First, removal of the code that is commented with "REMOVE THESE LINES ON 10 FEBRUARY 2009". Second, removal of the comment regarding DisableRealTitle, since this functionality is no longer present. Any objections? --- RockMFR 00:19, 17 February 2009 (UTC)

Just curious, what happened to the disable functionality? --MZMcBride (talk) 00:29, 17 February 2009 (UTC)
checkY Done. DisableRealTitle got dropped when I refactored the code last July. I didn't know it was there, but since nobody even noticed it until now it's probably not much of a loss. —Remember the dot (talk) 01:40, 17 February 2009 (UTC)

AJAX RC

On many, many other wikis I've seen the AJAX code for automatic RC. Why doesn't wikipedia, the most famous Wiki in the world, have it? If nobody knows what I mean, I can go fetch the JavaScript from my home-wiki. Timeroot (talk) 02:38, 18 February 2009 (UTC)

Where is MediaWiki:Common.js

Where do I find MediaWiki:Common.js, for example in LocalSetting.php or config file. Please help. Xxxsacheinxxx (talk) 15:29, 18 February 2009 (UTC)

For all intents and purposes, it's exactly where you linked to it at. Physically, it's in the database. 「ダイノガイ千？！」(Dinoguy1000) 20:23, 18 February 2009 (UTC)
I think he meant to ask where the file in invoked. — Edokter • Talk • 20:56, 18 February 2009 (UTC)

I've added a JS bit to add a link for iPhone, iPod Touch, and Android users to switch to the page on our mobile-optimized gateway at http://en.m.wikipedia.org/

This is our new gateway which is replacing the old http://en.mobile.wikipedia.org/ one, and currently is *much* nicer on higher-end mobile browsers. We're hoping to drive some more test traffic there, and do a bigger announcement in the next couple months. (Currently I've set it to only add the link on 25% of page views.)

Please file bugs in Bugzilla for any problems you encounter if you go exploring there! :)

In the future we'll swap this JS linking out for something more permanent. --brion (talk) 01:04, 19 February 2009 (UTC)

I'd like to tweak the wording from "in" to "on" and add a period after the link (div.appendChild(document.createTextNode("."));). Any objections from anyone? --MZMcBride (talk) 08:11, 19 February 2009 (UTC)
Works for me... I've gone ahead and tweaked that as well as bumping up the probabilistic display so it just always shows the link; no load probs yet. --brion (talk) 19:57, 19 February 2009 (UTC)

Technical restrictions bugfixes

I just fixed two minor problems with the "technical restrictions" code:

  1. The code did not work on pages outside the main namespace or pages in the main namespace that do not contain at least one wikilink.
  2. The code allowed the title bar to display a title completely different from the actual page title. This was particularly a problem for pages like Back and Forth (film), which previously showed up as <---> - Wikipedia, the free encyclopedia. If we can't represent the title properly, let's not pretend to. This is the same sentiment that Brion voiced in bug 12998.

—Remember the dot (talk) 21:13, 15 March 2009 (UTC)

Geonotice

There was talk on Wikipedia talk:Geonotice#Restoring geonotice functionality to bring back the unmaintained geonotices in a more community driven way after half a year of disuse. I've implemented it as User:Para/geonotice.js (to be moved into MediaWiki namespace?), which would be called from MediaWiki:Common.js/watchlist.js in two parts: 

importScriptURI('http://toolserver.org/~para/cgi-bin/geoip');
importScriptURI('http://en.wikipedia.org/w/index.php?title=User:Para/geonotice.js&action=raw&ctype=text/javascript&maxage=3600');

The first bit inserts the geographical coordinates of the requesting IP in json format in the watchlist page HTML. Hopefully a bit later, the second script compares admin added ranges to the coordinates from the first script and adds the given notice when they fit. There's a possibility for a race condition, but it's not an issue if notices aren't shown on the very first watchlist load. On caching, the geoip tool has max-age 12 hours and the Javascript with the notices has max-age 1 hour. Could people watching this page review? To test, see User:Para/monobook.js --Para (talk) 22:31, 17 March 2009 (UTC)

This looks great, Para. Thanks for your work on this.--Pharos (talk) 18:02, 20 March 2009 (UTC)
I agree. Looking good and will likely be much better maintainable. --TheDJ (talk • contribs) 18:48, 20 March 2009 (UTC)

What happened to Google

Resolved.
This question copied from Wikipedia talk:Searching#What happened to Google.

What's happened to the feature where you could use Google or other external search engines from within Wikipedia? BillMasen (talk) 16:06, 2 April 2009 (UTC)

I checked Special:Search and Bill is right, there are no longer the drop down box where one could choose which search engine to use. So I investigated:
The drop down box is added by MediaWiki:Common.js/search.js which is loaded from MediaWiki:Common.js. None of those pages have been edited lately. But it seems the rendered page code for Special:Search has been changed in such a way that /search.js doesn't work anymore. Since my Firefox error console reports:
(!) lStat.parentNode has no properties
    http://en.wikipedia.org/w/index.php?title=
      MediaWiki:Common.js/search.js&action=raw&ctype=text/javascript
And "lStat.parentNode" is part of the code in /search.js. It seems that is a fatal error since all javascript on the page stops. Unfortunately I am no java guru, so I can't see exactly what needs to be changed in the code so it will work again. But I bet some of you guys who usually edit these pages can fix it.
--David Göthberg (talk) 02:44, 3 April 2009 (UTC)
The reason is because of var lStat = searchForm.fulltext; The current version of Special:Search contains two fields named fulltext in the same form (one hidden field, and the submit button). This causes the browser to return an array of results for this specific code, and an array does not have a parentNode of course. This looks like a bug in the search page, and i dropped a line on IRC. I'll file a real bug tomorrow. --TheDJ (talk • contribs) 03:42, 3 April 2009 (UTC)
Ah yes, I see. Meanwhile, to fix it here without waiting for the devs to fix the page rendering: There is another hidden span tag right before that with name="title", I think we can use that one. So I think we should change this line:
var lStat = searchForm.fulltext;
To this:
var lStat = searchForm.title;
That should work, right?
--David Göthberg (talk) 05:50, 3 April 2009 (UTC)
Yes it should. It sounds like an acceptable work around. --TheDJ (talk • contribs) 09:56, 3 April 2009 (UTC)
bugzilla:18324 --TheDJ (talk • contribs) 11:56, 3 April 2009 (UTC)
Fixed in r49169. So the next software updated (tuesday likely) should restore this functionality. --TheDJ (talk • contribs) 13:16, 4 April 2009 (UTC)
Thanks for checking the code and filing the bug. I have now applied the javascript change I suggested above. Since from what I can see that will still work after they have deployed r49169, and we can't know how long time it till take until they do deploy r49169.
--David Göthberg (talk) 22:54, 4 April 2009 (UTC)

IE bugfix breaking IE?

This discussion is essentially how CollapsibleTables have just broken in IE7, for reasons that are difficult to determine given that IE has a bad crap f***ing awful error console. It's probably been aggravated by this edit, but I don't see anything fundamentally wrong with that particular layout for CollapsibleTables. I can get IE to say that the error is on "line 78" and that the error is "expected identifier"; which of the fifteen loaded JavaScript files it is referring to it neglects to mention. Line 78 of this file is right in the middle of the IE scrollbar fix. Could this be involved? If not, does anyone have any bright ideas what is causing this borkage? Happy‑melon 21:51, 9 April 2009 (UTC)

Is there a sandbox where the affected code can be tested? I have the IE DevToolbar which may tell me more. — Edokter • Talk • 22:22, 9 April 2009 (UTC)
I reverted the code on the main banner, but the sandbox is still running it; Template:WPBannerMeta/testcases has several examples of the sandbox code. I now think the "line 78" error is a separate issue; it occurs on every page I load on IE7 with "disable debugging" turned off, whether or not there's a collapsible table/WikiProject banner on the page. Happy‑melon 22:25, 9 April 2009 (UTC)
I see the problem; The Collapsible button code lookes for the first instance of a table header in the first instance of table row of the table to place the button in, as well as to hook the entire table on so it can hide it. In the sandbox code, the <TH> is chucked away as the last cell of a row, so it is no longer the first element in the first row. That is why the collapsible table no longer works. So you're going to have to make sure the the <TH> is the first element to appear in the table. — Edokter • Talk • 22:39, 9 April 2009 (UTC)
It's a bit easier in IE 8 to find the location of the error. Press F12 to bring up the Developer window then select the Script tab and press the Start Debugging button. The error occurs at Header.insertBefore( Button, Header.childNodes[0] ); in the createCollapseButtons function. -- WOSlinker (talk) 22:41, 9 April 2009 (UTC)
That seems a seperate issue; IE6 is not giving any error. — Edokter • Talk • 22:46, 9 April 2009 (UTC)
I think the problem is that the change to fix {{WPBannerMeta/core}} in Safari included this line: "<th style="padding-right:0.3em;"><!--SHOW/HIDE GOES HERE--></th>". IE7 seems to be failing when it tries to add the collapse button to the empty header cell. I think that the header cell needs to be non-empty or we need to change the collapsible table code to fix this for IE. I did some tests with Special:ExpandTemplates and if you put anything in the header cell then the JavaScript code works (of course whatever you add to the cell screws up the template, but at least we know where the error is coming from). --CapitalR (talk) 02:10, 10 April 2009 (UTC)
Edokter: Navbox sometimes doesn't have the header cell as the first cell in the row and it still works (see Template:US state navigation box). The JavaScript looks for the first header cell in the row, not the first element in the row, so I'm pretty sure that part of the code is okay. --CapitalR (talk) 02:13, 10 April 2009 (UTC)
So I just tested this out, and if we replace the line "<th style="padding-right:0.3em;"><!--SHOW/HIDE GOES HERE--></th>" with "<th style="padding-right:0.3em;"><div style="display:none;">blah</div></th>" then the new template seems to work fine in IE. This is a pretty dumb trick, so hopefully someone can think of something a little cleverer. --CapitalR (talk) 02:28, 10 April 2009 (UTC)
Change that line mentioned above to Header.insertBefore( Button, Header.firstChild );? Anomie⚔ 11:42, 10 April 2009 (UTC)
(←) OK, so there needs to be something in the header. Try a non-breaking space. But why not use the header what it was intended for; to contain the header text? — Edokter • Talk • 14:12, 10 April 2009 (UTC)
We wanted the centres of the headers to line up, and also for the two components of the header (the project name and any taskforces, and the "rated X-Class") to linewrap separately (pretty example). Essentially, they need to be in separate table cells. WPBM's outer table only has two rows; it was just two cells - a header that didn't collapse, and the body cell has a nested table that contains all the content. So I put another nested table in the header cell for the header block, which sort of worked. But you can't give the table explicit 100% width (or it linewraps to underneath the floating show/hide button) and without the explicit width Safari and Chrome screw up big time. The solution is, of course, to put the header block and the show/hide button in separate cells, but since the CollapsibleTables code puts the button in the first header cell it finds, we have to make all the other cells in the row normal cells, so there is only one header cell for it to plop the button into. Does that all make sense?
So, is it possible to fix the CollapsibleTables code, or do we need to put something in the header cell? Anomie's solution looks good at first glance. Happy‑melon 17:44, 10 April 2009 (UTC)

Disambig vs. disambigbox

When disambiguation pages are edited the {{disambig editintro}} is shown above them. It is code in MediaWiki:Common.js that detects when the CSS id "disambig" is present on a page and then makes it so the {{disambig editintro}} is loaded if/when the page is edited.

But we want to deprecate the "disambig" id. So I would like to change the CSS id used for the triggering to "disambigbox". But during the 31 days decaching time we must trigger on both ids.

So I would like to change this code: 

    if (document.getElementById('disambig'))
      addEditIntro('Template:Disambig_editintro');

To this: 

    if ( document.getElementById('disambig') || document.getElementById('disambigbox') )
      addEditIntro('Template:Disambig_editintro');

Background and details:

The disambig id is also used in MediaWiki:Common.css to declare some of the old styles for the disambig boxes. However using the id for styling is now deprecated since all disambig boxes nowadays use the {{dmbox}} meta-template, which instead uses the dmbox and mbox-* classes for its styles. But to keep triggering the {{disambig editintro}} we had to use the disambig id in {{dmbox}} too.

I dislike that the id was used for both styling and triggering, and I find the id name too generic to be clear. We have other things that are disambig related such as dablinks that do not (and should not) trigger the {{disambig editintro}}. Also, when {{dmbox}} is used for set index article boxes, then it instead sets the id "setindexbox" so it doesn't trigger the {{disambig editintro}}. But the id name "disambig" does not match with the id name "setindexbox".

So I want to change the id used in {{dmbox}} to "disambigbox". That is, the triggering of the {{disambig editintro}} is based on the presence of a disambiguation box, so "disambigbox" is clearer.

We of course have to wait 31 days after we have changed the javascript here, before we can change the id used in {{dmbox}}. Then we can remove the usage of "disambig" in the javascript here.

--David Göthberg (talk) 01:26, 16 April 2009 (UTC)

Makes sense. Might as well do this right away. --- RockMFR 02:54, 16 April 2009 (UTC)
Thanks. Yeah, I guess this was an obvious non-controversial addition.
And while I am at it, I just want to share a thought: I prefer to ask about almost all changes I do to these files for four reasons: It means I can write a full explanation why I do the change, which is good for future reference, since edit comments and code comments are often not enough to explain it properly. And writing it down often makes me realise things I had not realised, thus preventing some bugs or making my code better. And surprisingly often people come up with some improvements or additions even for "simple obvious" fixes like these. And sometimes we even screw up with simple code, so it is good to have a sanity check of ones code before deploying it.
--David Göthberg (talk) 09:33, 16 April 2009 (UTC)

IE PNG fixes break browser semantics and certain UI actions

In short, the current IE alpha transparency fix for IE <7 disrupts image semantics, which means that alt and title attributes are lost, image actions (save, print, e-mail) are missing from the context menu, and copying-and-pasting a selection that contains such a fixed image is broken.

My initial report of the problem (in which I was told to post on this talk page instead): Bugzilla:18470

My (simple) proposed fix: 18470 attachment

A demo showing an alpha transparency fix in IE that does not break the context menu, copy-and-paste, etc.: http://code.kliu.org/misc/fixiepng/demo.html

Kliu0x52 (talk) 11:45, 16 April 2009 (UTC)

Oh oh, now we need to find Windows users with IE6 installed :D If it works, i think it is a good suggestion btw. --TheDJ (talk • contribs) 11:57, 16 April 2009 (UTC)
I originally closed the bug report on Bugzilla. I have already tested the patch in my monobook.js, but unfortunaltely, it makes by browser hang completely (using IE6.0.2900 on Windows 2000). So we need some more testing if this is going to work. — Edokter • Talk • 12:17, 16 April 2009 (UTC)
Kliu0x52: The demo at http://code.kliu.org/misc/fixiepng/demo.html works fine in my very old IE 5.5. I see transparency, and I can right click and save the images correctly. I haven't tested your code version for MediaWiki:Common.js/IE60Fixes.js yet.
--David Göthberg (talk) 12:44, 16 April 2009 (UTC)
I tested the demo code on IE 6 in XP (I don't have Win2K to play with), but the demo code (which is something that I had written earlier for use on my own site) is obviously different than my proposed patch for Wikipedia. For starters, the demo hooks things up via a HTC behavior; but the general principle is still the same in both cases. Is there a way to test things here in Wikipedia, like some sort of a sandbox for JS changes? Kliu0x52 (talk) 13:08, 16 April 2009 (UTC)
Each user has their own monobook.js to play with; Special:Mypage/monobook.js. Here's my version that overrides the main script in IE6fixes.js. That is where I applied the patch, which resulted in hanging. I'll copy my version to your monobook.js, so you can experiment with the main script safely disabled. — Edokter • Talk • 13:26, 16 April 2009 (UTC)
Thanks! I'll play around with this later today, and make any fixes/adjustments to my proposed patch as necessary. Kliu0x52 (talk) 13:30, 16 April 2009 (UTC)
There is also a testpage here. If you experience a hang like I did, you need to disable javascript in your browser (or use Firefox) to revert the change, then purge your monobook.js and try again. — Edokter • Talk • 13:32, 16 April 2009 (UTC)

I seem to recall in the original discussion that someone mentioned there being far simpler ways to correct PNG transparency in IE via CSS or PHP. Am I just imagining things, or are there actually ways to do this, and if so, why aren't we looking at switching over to them (even if any PHP fix would require a bug report)? 「ダイノガイ千？！」(Dinoguy1000) 18:24, 16 April 2009 (UTC)

As I recall, none of those methods proved to be usable due to most images using borders, and javascript is the only way to account for that. — Edokter • Talk • 18:52, 16 April 2009 (UTC)
There's an IE6/pngfix method here (using javascript) that uses VML instead of AlphaImageLoader. I know AlphaImageLoader hasn't been explicitly mentioned above as a problem, but since the method seems fairly radically different, it may not have the problems mentioned above (breaking of semantics and performance) though I've not examined it at length of yet. ɹəəpıɔnı 17:20, 18 April 2009 (UTC)
Sounds interesting, but it's a big script (7KB). Still, might be worth investigating it's performance. — Edokter • Talk • 23:00, 18 April 2009 (UTC)
Retrieved from "https://en.wikipedia.org/w/index.php?title=MediaWiki_talk:Common.js/Archive_16&oldid=293053233"