This is an archive of past discussions about MediaWiki:Common.js. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.
I'm not sure what changes were made, but boxes no longer collapse automatically if there are more than two on a page - and there is no longer any spacing between them. Please see the bottom of the Paris article for an example. I'm using Safari on Mac os X 10.4.10 (intel). Cheers. THEPROMENADER07:58, 27 August 2007 (UTC)
See this diff. Why isn't the code at the bottom properly handled, causing the message to appear at the top of the page? —Ruud16:39, 28 August 2007 (UTC)
Because on diffs the content for .js/.css pages is not made "safe". This particular case could be fixed e.g. by using document.writeln('<'+'div style="position:absolute'…. Btw, I would really recommend nice and easy-on-the-server option "Don't show page content below diffs" ∴ Alex Smotrov17:06, 28 August 2007 (UTC)
Yeah, but the <code> tags are handeled correctly, and if you look at the source of the page you'll see that MediaWiki closes the <pre> tag. Why handle the these cases differently? —Ruud17:14, 28 August 2007 (UTC)
Let me put it this way: if you take the content of MediaWiki:Common.js and save it on some other (not .js/css) page, then you'll see the same mess on top, because the <div style="position:absolute'is interpreted as wikitext. Yes, another way to avoid this would be using <pre> Mediawiki tag (which is not the same as HTML <pre> tag). I'm not sure what you mean about <code> tags ∴ Alex Smotrov17:45, 28 August 2007 (UTC)
Appart from <div>-tags Common.js also contains <code>-tags. Those are just outputted as preformatted text on the diff pages, not unescaped HTML like the <div>-tags are. Apparently some developer went to the trouble of handling the two differently, I however, fail to see why. —Ruud21:41, 28 August 2007 (UTC)
Add code to automatically set collabsible table's show/hide button color
{{editprotected}}
This code will fix a problem in many navigation boxes where the header color is dark and the font color is light. The show/hide button always is dark blue, which means that with the dark background it cannot be read. This line will modify the color of the link if and only if a different header text color is specified in the table header. If the color is not changed, then the link will remain blue.
The anonnotice still isn't working correctly. I just opened Safari to see what it looked like, and three of them showed up at once, with two directly on top of each other. Don't know what the issue is, but I uploaded a screenshot (see here). --MZMcBride20:33, 3 September 2007 (UTC)
So thanks for all the cheese that's falling off my screen, and the fact that it's a new piece of cheese with every link I click. It would be nice if someone would turn down the cheese factor by at least three orders of magnitude. Did noone notice that <blink>blinking</blink> popups went out of fashion last century because of how distracting they are? Clearly not round here, they didn't. Then, if you're going to write your advert all over my screen, would you at least please have the consideration not to make it collide with article titles like Department for Business, Enterprise and Regulatory Reform? This fun-and-games with live Mediawiki pages is all well and good for logged-in users, but actually does affect people who are logged out. Like me, almost all the time I use Wikipedia, for example. Yes, yes, I know the pit of financial doom that the Foundation stares into all the time, but for the love of $deity, would someone come up with a scheme that is well thought-out, doesn't use up ever more real-estate with advertising, doesn't mess up formatting, doesn't require 30-odd edits to a super-important page to get right, doesn't distract me from reading articles and isn't instituted on the whim of a random admin. Oh, and would said random passing admins please test their new ideas somewhere else than on possibly the most-used page on the entire site? Thanks and appreciation in advance, Splash - tk12:18, 3 September 2007 (UTC)
Worse, it was showing a markup mistake (&bull with no semicolon) visible directly on the screen in Internet Explorer 6 for three hours (Firefox fixed the invalid markup to the correct markup automatically). I fixed that as soon as I logged on (and it was just chance that I happened to be using IE then, because I normally use Firefox), but 3 hours for a typo in anonnotice (which is almost as visible as sitenotice) is somewhat extreme. --ais523 14:02, 3 September 2007 (UTC)
Yes, it's somewhat extreme, and I will take full responsibility for it. You can castigate me if you'd like, but please don't blame others who did nothing wrong for my mistake. I'm sorry if the display was quite screwed up for a while, and hope that everything is now working correctly. —METS501 (talk)19:26, 3 September 2007 (UTC)
Splash, your tone could be more constructive here. Your complaint about Department for Business, Enterprise and Regulatory Reform was addressed over at MediaWiki_talk:Anonnotice#Clashes_with_not-unreasonably_long_titles as far as I can tell. Although perhaps I'm wrong because instead of following up about it there you're simply spreading your complaints all over in ForestFire fashion. Mets' minor errors here have been unfortunate, but he's going to be changing his process in the future. What important is that they were minor errors and that they've been resolved. It's good that Mets' took the time to take action to move us forward... bad that a little more care wasn't taken, but these are mistakes we can all learn from. There is no need to be rude about it. --Gmaxwell22:42, 3 September 2007 (UTC)
No, the problem with long article titles is not adequately addressed. Try logging out. The advertising still collides with long titles. I brought it up here because here is where the problem is, it having moved here from elsewhere. One additional mistake we can learn from is not to cover the screen in spam. Appeals for donations now appear 3 - count them - times on every page and are accompanied by other intrusive advertising besides. (Here is also the source of the spam, now, so mentioning that elsewhere would seem odd at best). Splash - tk09:03, 4 September 2007 (UTC)
I agree, I just logged out and it was pretty bad, with long article names or narrow windows. Can we move that variable link down to the "From Wikipedia, the free encyclopedia" line, which appears to be free, unlike where it is now? ←BenB409:36, 4 September 2007 (UTC)
Oh, crap, that's where we're putting coordinates. Make the title area (but not the font) five pixels taller in CSS? ←BenB409:54, 4 September 2007 (UTC)
Coincidentally, has anyone tried to obtain a diff between two previous versions of any page whilst logged out lately? There being nothing in this week's signpost indicating related changes, and the intermediate radio buttons disappearing at the same time as the spam randomises itself, I'm feeling a little suspicious. It could be another .js page altogether, of course. Splash - tk10:38, 4 September 2007 (UTC)
This was caused by the innerHTML rewriting code that mets put in with one of his changes. It looks like rewriting innerHTML causes pre-existing handles to dom objects inside to get invalidated. I confirmed that was the cause, and it's been removed. The message should be installed without rewriting the bodycontent div entirely. Until a fixed version has been tested the rotating lower notice should stay out. (upper notice isn't an issue) --Gmaxwell14:03, 4 September 2007 (UTC)
Much less sucky, and much improved article appearance. Constructive suggestion: instead of re-instating the (imo unimportant) spam on top of the article title, merge those messages into the rotating ones about funding. I suppose there is a desire somewhere to have more money messages than non-money messages, so wrap the random number selection up inside another one. The outer selection can be weighted as desired to indicate from which subset the message should be chosen; the message itself is selected from that subset by the existing random selection. Splash - tk15:12, 4 September 2007 (UTC)
To be clear, the article-title spam has been re-instated since I last got a cached page (there was no anonnotice spam briefly) which is mistaken and bad, and the Internet now sucks the more for it. At least it no longer stomps all over the actual content, though. Splash - tk15:17, 4 September 2007 (UTC)
On the subject of your 'constructive suggestions' ... if we were playing scrabble you would currently be suffering from a tremendous deficit of the letter s, p, a, and m. :) You can only call something crap that others think is a good idea so many times before your opinion starts to lose its weight. We are already abundantly aware that you think things like that donation notice are "spam", "advertisements", and any number of other nasty sounding things which are, no doubt, just the first step to completely selling out to Google or something like that.... It stopped being constructive about the 4th time you said it in the last two days. --Gmaxwell15:34, 4 September 2007 (UTC)
...and the *notice.js probably stopped being effective after the 4th time that the readers came across them for similar reasons. Though, I am at a loss to explain how you extrapolated to selling out to Google. Splash - tk15:49, 4 September 2007 (UTC)
I evaluated setting a cookie when a user sees or clicks a notice to prevent them from seeing another notice for a span of time, but we can't currently do this because even if the site itself will do nothing with the cookie as soon as it is set our squids will no longer cache the pages. If this happened with anons the site would instantly go hard-down. Once we can figure out how to do persistent client side storage that doesn't defeat caching we'll make these a little more smart.
The donation notices do, however, have a huge impact on our income. ... and the Wikipedia educational material is important because there is constant misunderstanding of Wikipedia, the press is never going to get it right, and if we don't take some action we and the public will continue to suffer because of it.
As far as the extrapolation goes, I was being a little mean.. Sorry. But it really isn't nice or fair to call the notices "spam", "advertisements", or "making the Internet suck".
Your commentary on the technical points, and raising the issue of the anonnotice hitting the title after it was removed from the commonjs the first time has been very helpful and I'm sure it is appreciated by all. But to me it seems your approach with the philosophical issue of reader targeted messages is very negative and largely built on loaded language rather than things we can discuss and come to agreement on. --Gmaxwell16:54, 4 September 2007 (UTC)
Well the diff buttons are fixed, but why would rewrting innerHTML invalidate logged-out users' handles but not logged in users'? ←BenB418:35, 4 September 2007 (UTC)
The reinstatement of this still clashed with article titles. It is to my mind completely unacceptable that it do so. The main difference between [1] and [2] appears to be the top:3px and font-size:100%, and so I've changed them to be the same as in mediawiki:anonnotice ie top:0px and font-size:80%. This has the effect of making the text look rather small, not sure why. But at least it no longer disrupts the title line(s).
Incidentally, why must there be so much formatting in these messages? There black, blue, grey, bold, italics, bullets and punctuation. dewiki just uses plain text and a link. Is that not enough? Splash - tk12:27, 5 September 2007 (UTC)
window.attachEvent("onload", PngFix) should be replaced with addOnloadHook (the former is specific to IE, but it's best to synchronize everything with the latter). I'm not too fond of innerHTML either, but if the script works, it works... GracenotesT§01:08, 9 September 2007 (UTC)
For IE in some cases window.addOnloadHook is not the same as onload event, so that change should have been tested first. Also, how about asking the devs to move the code into IEFixes.js instead? ∴ Alex Smotrov03:19, 9 September 2007 (UTC)
Yes, addOnloadHook is built into MediaWiki. (Not a function of the window object.) I think it's better to keep modifications of the DOM synchronous, hence addOnloadHook. Re IEFixes.js: that sounds like a good idea, although the function already exists as fixalpha(). Perhaps it doesn't work? :| GracenotesT§04:25, 9 September 2007 (UTC)
It appears to me that IEfixes.js only fixes the transparency on the Wikipedia logo. If someone would like to file a bug asking the developers to apply the fix to all images, by all means go right ahead. —Remember the dot(talk)04:47, 9 September 2007 (UTC)
The devs might not have implemented it because they didn't know how to make the code work quite right for all images. I had to tweak pngfix.js to specify "vertical-align:middle" or else it would mess up the layout in some cases. Maybe the devs tried but didn't figure out that they needed to set that one property. In any case, filing a bug (feature request, really) would probably be a good idea. —Remember the dot(talk)04:57, 9 September 2007 (UTC)
That looks like another Internet Explorer quirk. I fixed it by removing the font-size CSS parameter on the image's table cell. The parameter was only in there for text-only browsers (of which there are few), so it's no big loss. But you can avoid the problem entirely by just not using old versions of IE. —Remember the dot(talk)19:34, 9 September 2007 (UTC)
Thanks for identifying and resolving the problem. I use Firefox, but I try to make sure that things are working as well as possible for people running older IE versions.
A bug has been identified which causes borders to fail to display in IE 5.5 and 6. I believe that changing the code to make images into divs instead of spans will resolve this. So, please change the PngFix function to read:
Never mind - changing it to a div would probably break more things than it fixes. Instead, try changing sizingMethod='scale' to sizingMethod='image' —Remember the dot(talk)00:31, 10 September 2007 (UTC)
Changing the sizingMethod='image' has fixed the distortion on some flags, but the border problem persists. Interestingly, flag icons that are still based on jpg images do show the grey border. It's just PNG and SVG that do not. Andrwsc00:38, 10 September 2007 (UTC)
OK, then try switching from using spans to using divs. This isn't standards-compliant, but Internet Explorer doesn't seem to care (surprise, surprise). For reference, the code would be:
OK, I've found a fix (and tested it in my userpace on the Commons), but you'll have to edit two files. Change the pngfix code to read:
Code
/*
Correctly handle PNG transparency in Win IE 5.5 & 6.
http://homepage.ntlworld.com/bobosola. Updated 18-Jan-2006.
Tweaked 10 Sep 2007 (UTC) by Remember_the_dot so that it works properly inside Common.js
http://homepage.ntlworld.com/bobosola/pnginfo.htm states "This page contains more information for the curious or those who wish to amend the script for special needs", which I take as permission to modify or adapt this script freely. I release my changes into the public domain.
*/
function PngFix()
{
if (document.body.filters)
{
for(var i=0; i<document.images.length; i++)
{
var img = document.images[i]
var imgName = img.src.toUpperCase()
if (imgName.substring(imgName.length-3, imgName.length) == "PNG")
{
var imgID = (img.id) ? "id='" + img.id + "' " : ""
var imgClass = (img.className) ? "class='" + img.className + "' " : ""
var imgTitle = (img.title) ? "title='" + img.title + "' " : "title='" + img.alt + "' "
var imgStyle = "display:inline-block; vertical-align:middle;" + img.style.cssText
if (img.align == "left") imgStyle = "float:left;" + imgStyle
if (img.align == "right") imgStyle = "float:right;" + imgStyle
if (img.parentElement.href) imgStyle = "cursor:hand;" + imgStyle
var strNewHTML = "<span " + imgID + imgClass + imgTitle
+ " style=\"font-size:0; display:inline-block;" + imgStyle + "\"><span style=\'width:" + img.width + "; height:" + img.height + "; display:inline-block; filter:progid:DXImageTransform.Microsoft.AlphaImageLoader"
+ "(src=\"" + img.src + "\', sizingMethod='image');\"></span></span>"
img.outerHTML = strNewHTML
i = i-1
}
}
}
}
if (navigator.appName == "Microsoft Internet Explorer")
{
var version = parseFloat(navigator.appVersion.split("MSIE")[1])
if (version <= 6 && version >= 5.5)
{
window.addOnloadHook(PngFix)
}
}
/* Enables borders on PNG images in IE 5.5 and 6 */
.thumbborder {
border:1px solid #DDDDDD;
}
In the future, the Mediawiki software may do all this automatically. But as for right now, we have to work with what we've got.
For the technically minded, I moved all the CSS styling information to a span outside the image, and made the image's span separate. I had to set the font-size property of the outer span to 0 in order to make it shrink-wrap the inner span. —Remember the dot(talk)03:34, 10 September 2007 (UTC)
addOnloadHook is not specifically a function of the window object, so that might need to be altered. I do realize philosophy differs on this, but it might be a good idea to have some discussion of an {{editprotected}} request before it's implemented. But, again, this is a wiki. Things are reversible. GracenotesT§06:16, 10 September 2007 (UTC)
I will attemt to clean up the code a bit, because I already discovered a double 'style=' and a 'display:inline-block' declaration within the same span, which is just awfull coding. I will conduct some tests myself to find out which fix really fixed the border; maybe simply adding the .thumborder would have sufficed. Will report back later. — Edokter • Talk • 13:46, 10 September 2007 (UTC)
I'm surprised it even WORKS! I see so many syntax errors in the code above (" and ' mixed, missing "px" in width and height parameters, etc.), but when I test my cleaned up code, the image diappears! This is maddening... — Edokter • Talk • 19:46, 10 September 2007 (UTC)
OK, got the cleanup done! only problem remains the ' and " in the image (hint) title: if I use ' , all text in the hint past a ' is truncated. If i use ", everything after " is truncated. If I use no quotes, everything after the first space disappears... I need a thridt quote character. :/ My code is here: http://commons.wikimedia.org/wiki/User:Edokter/monobook.js — Edokter • Talk • 21:44, 10 September 2007 (UTC)
Now I find my edit toolbar on Commons don't work... (Update:) Must be a Commons problem, as the original code here also has this problem on Commons. But not here though... — Edokter • Talk • 22:16, 10 September 2007 (UTC)
Here is a cleaned-up version of the code. I have tested it in my userspace on the Commons and believe that it will resolve the title attribute issues.
Code
/*
Correctly handle PNG transparency in Win IE 5.5 & 6.
http://homepage.ntlworld.com/bobosola. Updated 18-Jan-2006.
Tweaked 11 Sep 2007 (UTC) by Remember_the_dot so that it works properly inside Common.js
http://homepage.ntlworld.com/bobosola/pnginfo.htm states "This page contains more information for the curious or those who wish to amend the script for special needs", which I take as permission to modify or adapt this script freely. I release my changes into the public domain.
*/
function PngFix()
{
if (document.body.filters)
{
for(var i = 0; i < document.images.length; i++)
{
var img = document.images[i]
var imgName = img.src.toUpperCase()
if (imgName.substring(imgName.length - 3, imgName.length) == "PNG")
{
var imgID = (img.id) ? "id=\"" + img.id + "\" " : ""
var imgClass = (img.className) ? "class=\"" + img.className + "\" " : ""
var imgTitle = (img.title) ? "title=\"" + img.title + "\" " : ""
var imgStyle = "display:inline-block; font-size:0; vertical-align:middle;" + img.style.cssText
if (img.align == "left") imgStyle = "float:left;" + imgStyle
if (img.align == "right") imgStyle = "float:right;" + imgStyle
if (img.parentElement.href) imgStyle = "cursor:hand;" + imgStyle
var strNewHTML = "<span " + imgID + imgClass + imgTitle + " style=\"" + imgStyle + "\"><span style=\"width:" + img.width + "px; height:" + img.height + "px; display:inline-block; filter:progid:DXImageTransform.Microsoft.AlphaImageLoader(src='" + img.src + "');\"></span></span>"
img.outerHTML = strNewHTML
i--
}
}
}
}
if (navigator.appName == "Microsoft Internet Explorer")
{
var version = parseFloat(navigator.appVersion.split("MSIE")[1])
if (version <= 6 && version >= 5.5)
{
window.addOnloadHook(PngFix)
}
}
Well, I found a new (small) problem. Have a look at {{resolved}} source and talk page. Apparrently the filter doesn't like exotic unicode characters in the image filename. There is probably no fix but to 'ban' exotic unicode in filenames (not sure what the policy is on that anyway). — Edokter • Talk • 16:26, 11 September 2007 (UTC)
As far as I can tell, the filename is passed to the filter correctly, but after some digging, I think I found the cause: it is indeed AlphaImageLoader that is not handling the src parameter correctly. Here's some interesting reading: here. — Edokter • Talk • 22:25, 11 September 2007 (UTC)
I wouldn't call it "exotic unicode" since I would consider Latin-1 characters pretty darn universal. (But you have a point with the atrociously named Image:☑.svg!!) Some other images that fail to render are Image:Bandera d'Öland.svg and Image:Île-de-France flag.svg. I don't think a massive renaming effort on Commons is the solution here, since that wiki is used by so many languages that use characters beyond good old ASCII. I would expect plenty of image names with Latin-1 characters to be created perpetually after any renaming is "complete". We need another solution. Andrwsc00:52, 12 September 2007 (UTC)
☑ (which by now I found out is (U+2611) isn't latin-1; it's part of the "Miscellaneous Symbols" block see [3]. The only fonts I could find that displays this character is Arial Unicode and MS UI Gothic. IE6 Seems to have a problem showing it (not Firefox), I still consider it an 'exotic' character, because not many fonts support it. — Edokter • Talk • 11:44, 12 September 2007 (UTC)
Yes, of course, I agree that ☑ is a terrible filename, and I would clearly call that character "exotic". My point was that characters like Ö and Î aren't really "exotic" and therefore, we couldn't easily enforce a ban of them in image filenames just to support this fix. It's a moot point now anyway. Andrwsc19:14, 13 September 2007 (UTC)
I never suggested that all unicode be banned, just that these 'exotic' ones be avoided in filenames. I have no problem with leters like öÎñéôÛáÈ (áñd whât èlsé); they are part of a language, and thus part of a codepage. That character isn't, which causes problem with readability (not only on IE6 btw), not to mention typeability. So yeah, in that respect I say ban those non-linguistic characters from filenames. — Edokter • Talk • 19:31, 13 September 2007 (UTC)
The fix for the Unicode image naming problem is actually quite simple. I've debugged it on Commons and (with the help of [4], kudos to Edokter) found a fix. Just change
Cheers Dot & MZ! I promise not to panic again if I find another bug (which I suspect won't happen for a long time). — Edokter • Talk • 11:46, 12 September 2007 (UTC)
By the way, I'm working on an optimized version of the code that will hopefully run much faster than the current version. Please be patient; I'll probably have it done within 24 hours. —Remember the dot(talk)18:56, 13 September 2007 (UTC)
Besides javascript to get IE6 to render PNS correctly, there are also other methods that may in the end be a better sulotion for MediaWiki. There are "CSS only" implementations, and even PHP solutions. This may be worth looking into in the long run. Just a thought... — Edokter • Talk • 21:56, 13 September 2007 (UTC)
Optimized code
I went through and optimized the code to reduce unneccessary processing. Give this a try:
Code
/*
Correctly handle PNG transparency in Win IE 5.5 & 6.
http://homepage.ntlworld.com/bobosola. Updated 18-Jan-2006.
Adapted for Wikipedia by Remember_the_dot
http://homepage.ntlworld.com/bobosola/pnginfo.htm states "This page contains more information for the curious or those who wish to amend the script for special needs", which I take as permission to modify or adapt this script freely. I release my changes into the public domain.
*/
function PngFix()
{
if (document.body.filters)
{
var documentImages = document.images
for (var i = 0; i < documentImages.length;)
{
var img = documentImages[i]
var imgSrc = img.src
if (imgSrc.substr(imgSrc.length - 3).toLowerCase() == "png")
{
var imgID = (img.id) ? "id=\"" + img.id + "\" " : ""
var imgClass = (img.className) ? "class=\"" + img.className + "\" " : ""
var imgTitle = (img.title) ? "title=\"" + img.title + "\" " : ""
var imgStyle = "display:inline-block; font-size:0; vertical-align:middle;" + img.style.cssText
if (img.parentElement.href) imgStyle = "cursor:hand;" + imgStyle
img.outerHTML = "<span " + imgID + imgClass + imgTitle + " style=\"" + imgStyle + "\"><span style=\"width:" + img.width + "px; height:" + img.height + "px; display:inline-block; filter:progid:DXImageTransform.Microsoft.AlphaImageLoader(src='" + encodeURI(imgSrc) + "');\"></span></span>"
}
else
{
i++
}
}
}
}
if (navigator.appName == "Microsoft Internet Explorer")
{
var version = navigator.appVersion.substr(22, 3)
if (version == "6.0" || version == "5.5")
{
window.addOnloadHook(PngFix)
}
}
Now, even though I did cut out a bunch of unneccessary processing, I left in support for images with id and title attributes even though the MediaWiki software usually does not use these attributes on images. I didn't want to have this code work in most cases but seemingly randomly mess up the page's XHTML in others. —Remember the dot(talk)04:45, 14 September 2007 (UTC)
Thinking about this, I realized why the code has been dramatically slowing page load times on IE6. It's because the MediaWiki function "window.addOnloadHook" is executed before all the images load, causing the script to make browser the wait for every single image to load before displaying the page. Here is a revised version of the code that goes back to using "window.attachEvent", which will allow the browser to load all the images (though with opaque backgrounds) before changing the backgrounds to transparent. The end result for the user will be the ability to use the page freely with opaque backgrounds until all the images load, then the page will freeze for a moment (the user probably won't even notice this) while the backgrounds are made transparent.
This code also disables running the script on an image if the image uses an imagemap. In the current "live" script there is a bug that causes imagemaps to fail to work with PNG/SVG images.
Code
/*
Correctly handle PNG transparency in Win IE 5.5 & 6.
http://homepage.ntlworld.com/bobosola. Updated 18-Jan-2006.
Adapted for Wikipedia by Remember_the_dot
http://homepage.ntlworld.com/bobosola/pnginfo.htm states "This page contains more information for the curious or those who wish to amend the script for special needs", which I take as permission to modify or adapt this script freely. I release my changes into the public domain.
*/
function PngFix()
{
if (document.body.filters)
{
var documentImages = document.images
for (var i = 0; i < documentImages.length;)
{
var img = documentImages[i]
var imgSrc = img.src
if (imgSrc.substr(imgSrc.length - 3).toLowerCase() == "png" && !img.useMap)
{
var imgID = (img.id) ? "id=\"" + img.id + "\" " : ""
var imgClass = (img.className) ? "class=\"" + img.className + "\" " : ""
var imgTitle = (img.title) ? "title=\"" + img.title + "\" " : ""
var imgStyle = "display:inline-block; font-size:0; vertical-align:middle;" + img.style.cssText
if (img.parentElement.href) imgStyle = "cursor:hand;" + imgStyle
img.outerHTML = "<span " + imgID + imgClass + imgTitle + " style=\"" + imgStyle + "\"><span style=\"width:" + img.width + "px; height:" + img.height + "px; display:inline-block; filter:progid:DXImageTransform.Microsoft.AlphaImageLoader(src='" + encodeURI(imgSrc) + "');\"></span></span>"
}
else
{
i++
}
}
}
}
if (navigator.appName == "Microsoft Internet Explorer")
{
var version = navigator.appVersion.substr(22, 3)
if (version == "6.0" || version == "5.5")
{
window.attachEvent("onload", PngFix)
}
}
As of July 2007, about 38% of browser views were with IE5 or IE6 (see here). It's simply not practical to suggest that millions of potential users upgrade immediately. Adoption will take time. For the same reason, I would say that the Wikipedia experience is also way better on a large monitor (like my widescreen cinema display at home!), but since 2/3 of all users view with 1024x768 or smaller, we have to design pages for that. Andrwsc22:08, 14 September 2007 (UTC)
I'm not forcing users to upgrade, I'm merely strongly recommending it. Why would I write a script for IE6 if I was trying to force IE7 or Firefox on everyone? —Remember the dot(talk)22:20, 14 September 2007 (UTC)
I found another possible problem, hopefully related the window.addOnloadHook method an possibly fixed by the change to window.attachEvent. Wikipedia:Route diagram template containes a partially collapsed table containing SVGs. When clicking 'Show', I see no images in the resulting area being expanded, probably because they haven't been rendered yet? — Edokter • Talk • 22:49, 14 September 2007 (UTC)
Maybe that particular page (over 400! SVGs) overloads the filter. BTW, now that it is changed to window.attachEvent, the filter still stalling IE after loading all the images, which may be related to the asynchronous loading of images described inthe article I mentioned earlier. — Edokter • Talk • 23:59, 14 September 2007 (UTC)
Just so you know, the last code revision shifted the temporary freeze from before the page loads to after. This gives the user a chance to start reading the text of the article, and with any luck they'd be so caught up in that that they wouldn't notice the momentary freeze. On pages with just a few PNG or SVG images, the freeze is imperceptible anyway. —Remember the dot(talk)05:00, 15 September 2007 (UTC)
In order to resolve the issues that the previous code caused, I request that the PngFix function be changed as follows:
Code
function PngFix()
{
if (document.body.filters)
{
var documentImages = document.images
for (var i = 0; i < documentImages.length; i++)
{
var img = documentImages[i]
var imgSrc = img.src
if (imgSrc.substr(imgSrc.length - 3).toLowerCase() == "png")
{
img.style.filter = "progid:DXImageTransform.Microsoft.AlphaImageLoader(src='" + encodeURI(imgSrc) + "')"
img.src = "http://upload.wikimedia.org/wikipedia/commons/d/db/Must_left-click_image_again_before_saving.gif"
if (img.parentElement.href)
{
img.style.cursor = "hand"
}
}
}
}
}
This makes use of a different solution, leaving the img tags intact but filling in the proprietary filter property and then changing the src attributes to point to a 1px transparent GIF image. This allows for much faster code, support for imagemaps, resolves issues with the editing toolbar, and even allows MediaWiki's checkered image background to be displayed. The only downside is that the "Save Picture As" right-click menu item will try and save the 1px transparent GIF image instead of the image the user actually sees. I've tried to mitigate the problem as best I can by naming the image Image:Must left-click image again before saving.gif. —Remember the dot(talk)17:10, 15 September 2007 (UTC)
It is lightning fast. Unfortunately, it breaks the border and thumb parameters again. This could be fixed using a CSS class, ie, .img.pngfixed. — Edokter • Talk • 19:44, 15 September 2007 (UTC)
OK, this may sound drastic, but maybe the script should be removed from Common.js alltogether until all issues are resolved. That also allows for testing here on en:. — Edokter • Talk • 22:55, 15 September 2007 (UTC)
Just hold on. Some templates have already switched to using SVG images and thus have become dependent on the functionality provided by this script. —Remember the dot(talk)23:20, 15 September 2007 (UTC)
Well, I couldn't get the lightning-fast version to work right, but here is a revised copy of PngFix() which will add support for transparency + imagemaps, support for the checkered background, and last if not least fix the edit toolbar problem.
Code
function PngFix()
{
if (document.body.filters)
{
var documentImages = document.images
for (var i = 0; i < documentImages.length;)
{
var img = documentImages[i]
var imgSrc = img.src
if (imgSrc.substr(imgSrc.length - 3).toLowerCase() == "png" && !img.onclick)
{
var imgID = (img.id) ? "id=\"" + img.id + "\" " : ""
var imgClass = (img.className) ? "class=\"" + img.className + "\" " : ""
var imgTitle = (img.title) ? "title=\"" + img.title + "\" " : ""
var imgStyle = "display:inline-block; font-size:0; vertical-align:middle;" + img.style.cssText
var imgUseMap = (img.useMap) ? "usemap=\"" + img.useMap + "\" " : ""
if (img.parentElement.href) imgStyle = "cursor:hand;" + imgStyle
img.outerHTML = "<span " + imgID + imgClass + imgTitle + " style=\"" + imgStyle + "\"><img src=\"http://upload.wikimedia.org/wikipedia/commons/d/db/Must_left-click_image_again_before_saving.gif\" style=\"width:" + img.width + "px; height:" + img.height + "px; display:inline-block; filter:progid:DXImageTransform.Microsoft.AlphaImageLoader(src='" + encodeURI(imgSrc) + "');\"" + imgUseMap + "/></span>"
}
else
{
i++
}
}
}
}
What was the problem? Imagemaps? The last version worked quite well and seemd indeed faster then the current one (though I would have to time both; is the img.outerHTML line the only difference apart from && !img.onclick ? ) — Edokter • Talk • 00:29, 16 September 2007 (UTC)
OK, speed difference is minimal. Using img src made the image pop down 1px. Border/thumb works, toolbar works. I say go for it. Just curious what problem you found though. Oh and, should we clean up all the old code above, only leaving the current? — Edokter • Talk • 00:53, 16 September 2007 (UTC)
The problem with the code posted to the top of this section is that it broke the links on every single image, making it impossible to click the image and get to its description page. And I'd prefer to leave all the discussion pages alone (don't cut the code out of them or anything). Just let this whole long section be archived in due time. —Remember the dot(talk)05:04, 17 September 2007 (UTC)
Which version of the code should be changed to? Which change, exactly, should be made? There are a lot of suggestions in the above thread, and I'm not sure which one the request is to change. --ais523 14:38, 17 September 2007 (UTC)
Only the last change proposed by Remember the dot should be made to the current version for now; that will restore the editbuttons. — Edokter • Talk • 16:08, 17 September 2007 (UTC)
DoneDone. Personally, I'd recommend trying to get the "fast", non-inner/outerHTML based version working, since it looks like the only one that isn't likely to have such problems with unexpected attributes. Unfortunately, I don't have IE at home so I can't help with this much. —Ilmari Karonen (talk) 18:52, 17 September 2007 (UTC)
I agree on the fast version, but that will take some time testing to get all the bugs out. I'm sure Remember the dot is still working on it, and I will do some testing on my own. Stay tuned. — Edokter • Talk • 19:39, 17 September 2007 (UTC)
Actually, I have not come up with any new way to fix all the problems perfectly, and I am not actively working on it. The code as it now stands should work for most if not all cases. That said, for increased flexibility I should probably write an algorithm to abort pngfixing an image if there are any unexpected attributes (not just usemap and onclick).
Actually, now I'm working on rewriting the code to avoid using proprietary properties (like outerHTML and innerHTML). We'll have to see if this new approach is any faster. —Remember the dot(talk)21:17, 19 September 2007 (UTC)
More standards-compliant version
I've modified the code to avoid using outerHTML to better comply with W3C standards, but the new code does not appear to be significantly faster. Would anyone else be willing to test this new code on, say, Commons:Category:Icons for railway descriptions, and let me know if it appears to go any faster?
Code
function PngFix()
{
if (document.body.filters)
{
var documentImages = document.images
for (var i = 0; i < documentImages.length;)
{
var img = documentImages[i]
var imgSrc = img.src
if (imgSrc.substr(imgSrc.length - 3).toLowerCase() == "png" && !img.useMap && !img.onclick)
{
var outerSpan = document.createElement("span")
var innerSpan = document.createElement("span")
var outerSpanStyle = outerSpan.style
var innerSpanStyle = innerSpan.style
outerSpan.id = img.id
outerSpan.className = img.className
outerSpan.title = img.title
outerSpanStyle.cssText = img.style.cssText
outerSpanStyle.display = "inline-block"
outerSpanStyle.fontSize = "0"
outerSpanStyle.verticalAlign = "middle"
if (img.parentElement.href) outerSpanStyle.cursor = "hand"
innerSpanStyle.width = img.width + "px"
innerSpanStyle.height = img.height + "px"
innerSpanStyle.display = "inline-block"
innerSpanStyle.filter = "progid:DXImageTransform.Microsoft.AlphaImageLoader(src='" + encodeURI(imgSrc) + "')"
outerSpan.appendChild(innerSpan)
img.parentNode.replaceChild(outerSpan, img)
}
else
{
i++
}
}
}
}
While I'm usually all for standards compliance, in this case I don't think it's much of a priority, given that the code is meant to run only on specific versions of a single browser. Of course, I have nothing actually against it, either. —Ilmari Karonen (talk) 03:23, 20 September 2007 (UTC)
I would prefer it for no other reason than to encourage standards-compliant JavaScript insofar as it is possible. But I was hoping that someone would be able to test the standards-compliant version and give a definitive answer as to whether it is faster or slower than the currently live code. The two seemed about the same when I tested them. —Remember the dot(talk)03:46, 20 September 2007 (UTC)
if (img.parentElement.href) outerSpanStyle.cursor = "hand"
Should be:
if (img.parentElement.href) innerSpanStyle.cursor = "hand"
Otherwise seems OK, not faster though, but I think the bulk of the speed is lost in the filter itself, not the javascript. Also, the images seem to load twice using the span method, something that was not the case with the src=blank.gif, which does speed up a bit. — Edokter • Talk • 20:40, 21 September 2007 (UTC)
Actually, the bug was needing to change
outerSpanStyle = img.style
to
outerSpanStyle.cssText = img.style.cssText
All of the CSS styling for the outer span wasn't actually being applied. Thanks for catching that!
1px transparent image version
But...from your comments it sounded like you weren't having any problems with the solution that involves a 1px transparent image. So I tried that solution again and was not able to reproduce the problems I was having with it earlier. Here is a simplified version of that script, please let me know if it works all right for you:
Code
function PngFix()
{
if (document.body.filters)
{
var documentImages = document.images
var documentImagesLength = documentImages.length
for (var i = 0; i < documentImagesLength; i++)
{
var img = documentImages[i]
var imgSrc = img.src
if (imgSrc.substr(imgSrc.length - 3).toLowerCase() == "png")
{
if (img.className == "thumbimage" || img.className == "thumbborder")
{
img.width = img.width - 2
img.height = img.height - 2
}
img.style.filter = "progid:DXImageTransform.Microsoft.AlphaImageLoader(src='" + encodeURI(imgSrc) + "', sizingMethod='crop')"
img.src = "http://upload.wikimedia.org/wikipedia/commons/d/db/Must_left-click_image_again_before_saving.gif"
}
}
}
}
Galley transparency works (checkered background), edit buttons work (even without the && !img.useMap && !img.onclick checks, don't know about imagemaps though, where can I find one on Commons?), but still has a problem with |border and |thumb attributes (image jumps up 1 or 2px, plus left 1px in left floats, and right/bottom border disappears).
Putting back sizingMethod='scale' seems to fix that problem, but then I see the image grow by 2 pixels as the filter is being applied. So it seems it doesn't quite handle the surrounding border properly. My testpage shows that quite clearly here. — Edokter • Talk • 11:02, 22 September 2007 (UTC)
I've put in code that fixes the thumbborder/image mispacement. Not optimized, but it works. Scrap that, I found an even simpler sulution: sizingMethod='crop'! — Edokter • Talk • 11:39, 22 September 2007 (UTC)
A test on nl.wiki shows that this code is significantly faster then the span method. Also a plus for this version: the added .thumbborder class is no longer needed in Common.css. — Edokter • Talk • 12:13, 22 September 2007 (UTC)
Ah, now I remember why I didn't recommend using this 1px version + sizingMethod='crop'. It causes images to jump by a pixel or two when a border is used. Try [[Image:Tournesol.png|100px|border]] and you'll see what I mean. —Remember the dot(talk)21:34, 22 September 2007 (UTC)
In that case, the only solution I can provide is this snipplet:
The only downside is that the border overlaps the image instead of enclosing it, basically cropping the image by 1px, but I think that's an acceptable compromise; I prefer the speed increase over the span method and can live with the virtually undetectable smaller image. — Edokter • Talk • 23:07, 22 September 2007 (UTC)
I'm afraid this solution is unacceptable for two reasons. First, any alteration of the image's dimensions is unacceptable, as it could break the layout in some exotic cases. Second, your code relies on the image's border with being 1, and is hard-coded to that value. This will break if the border's width is ever changed. —Remember the dot(talk)20:48, 24 September 2007 (UTC)
(Deindent) OK, here's some brainstorming... is it possible to enclose the <img> within a span (as opposed to two spans), and have the span implement the border instead? (Edit: You tried this above). I still prefer this version, and I don't share your concern; First, the image dimension isn't really changed, and exotic layouts wouldn't normally use a border anyway. 2nd, I believe .thumborder and .thumbimage are not likely to be changed. — Edokter • Talk • 21:26, 24 September 2007 (UTC)
The answer is still no. Let's think about your proposal for a minute.
Pros: Slightly decreased page load time, support for checkered background
Cons: Fragile, hard-coded values, significant potential for breaking or distorting pages
I wish just as much as you do that we could perfectly compensate for IE's quirky behavior. But honestly, the added speed and functionality you recommend is so little compared to the added problems this would create both now and in the future. the Any change that deviates from normal layout or presentation is unacceptable, especially when based on hard-coded values which may work today and break tomorrow. —Remember the dot(talk)01:50, 25 September 2007 (UTC)
Make that signifcantly faster load times. The current code tends to lock up IE6 up to a minute when loading a page with 100+ PNGs, plus it ignores all imagemaps. I'd rather have the code removed entirely then have to deal with the wait time. I'll do some more tests with the combined code, but we should fret over 'hard-coded' values; Wikipedia of full of them. And also remember that it only impacts IE5.5/6.0, which is already "broken". — Edokter • Talk • 09:01, 25 September 2007 (UTC)
First, the page freeze time is less than 5 seconds with the currently live code, and that's on a page with 200+ PNG/SVG images. On nearly all pages the page freeze time is less than 1 second. Most users will probably be too busy reading to even notice it.
Second, your personal preference, "I'd rather have the code removed entirely then have to deal with the wait time", is, sorry to say, rather irrelevant. The goal here was not to cater to the preferences of a single IE6 user. The goal was to correct one aspect of IE6's flawed behavior in certain circumstances so that the rest of us wouldn't have to worry so much about coding Wikipedia around it.
The goal was not to make IE6 render some pages better and some pages worse. This would just lead to a backlash and people puzzling over why things that worked before do not behave quite right now.
IE6 users have been asked for some time to either use a different browser, such as Firefox, or upgrade to version 7. If you're annoyed with poor performance in IE6, then why have you chosen not to do this?
I am seriously beginning to question your motives to put this script up in the first place; Are you trying to scare evey IE6 user away from it? It is not a mere 5 seconds, it's 65 seconds on Wikipedia:Route diagram template (on a 1.4GHz), which is very bad. The <img> code reduces it to 12. Now you won't compromise on a solution that would actually make the experience for IE6 user better, and now we're stuck with a half-working version. Tell you what... I'll come up with a solution myself and put that in; it won't distort the images and will make loading a lot faster for the majority of IE6 users.
That's odd...when I was testing it before on the Commons, I only got an additional 5 seconds. I welcome your input, but I do not think that the solution you proposed is acceptable. Surely, though, you understand that IE6 is inferior to IE7, Firefox, Opera, Safari, and several others. You are doing yourself a disadvantage by continuing to use IE6.
Now, I took another look at the code that changes each image's source to a 1px transparent GIF (I actually could have used an indexed PNG, but the file size would have been slightly larger) and then encapsulates that element within a <span>. I discovered that the reason it wouldn't work right is because the outer span's display style must not be "inline-block" for this solution. Here is some new code based on that idea that seems to work without problems:
Code
function PngFix()
{
if (document.body.filters)
{
var documentImages = document.images
for (var i = 0; i < documentImages.length; i++)
{
var img = documentImages[i]
var imgSrc = img.src
if (imgSrc.substr(imgSrc.length - 3).toLowerCase() == "png")
{
var outerSpan = document.createElement("span")
var outerSpanStyle = outerSpan.style
var imgStyle = img.style
outerSpan.className = img.className
outerSpanStyle.cssText = img.style.cssText
outerSpanStyle.fontSize = "0"
outerSpanStyle.hasLayout = "true"
img.className = ""
imgStyle.cssText = ""
imgStyle.verticalAlign = "middle"
imgStyle.filter = "progid:DXImageTransform.Microsoft.AlphaImageLoader(src='" + encodeURI(imgSrc) + "')"
img.src = "http://upload.wikimedia.org/wikipedia/commons/d/db/Must_left-click_image_again_before_saving.gif"
img.parentNode.replaceChild(outerSpan, img)
outerSpan.appendChild(img)
}
}
}
}
The above code doesn't show the borders at all, and all images jump 1px to the left and down. Sorry if I seem a bit frustrated. I just think if it can be done right, it should be. I have been brainstorming a bit, and have come up with a mix of both methods, depending if there is a border or not. I just need to figure out how to create a outer span (I'm not that good in javascript); Here's the code I have tested so far; if you can integrate the above code into that part that needs a span, I think we actually have a very good solution:
Code
function PngFix()
{
if (document.body.filters)
{
var documentImages = document.images
for (var i = 0; i < documentImages.length; i++)
{
var img = documentImages[i]
var imgSrc = img.src
if (imgSrc.substr(imgSrc.length - 3).toLowerCase() == "png")
{
img.src = "http://upload.wikimedia.org/wikipedia/commons/d/db/Must_left-click_image_again_before_saving.gif"
img.style.filter = "progid:DXImageTransform.Microsoft.AlphaImageLoader(src='"
+ encodeURI(imgSrc) + "', sizingMethod='crop')"
if (img.className == "thumbborder" || img.className == "thumbimage")
{
img.style.border = "none" // remove current border first
// create container span with parent class style to put img tag in.
}
}
}
}
}
That way, borderless images load fast (and pages with lots of images ususally don't have borders), while those with border are encapsulated in a span with border. No distortions, best of both worlds. — Edokter • Talk • 13:31, 26 September 2007 (UTC)
Why can't I get any style information from img.style? it always comes back empty or 'undefined'. I can set it, but not read it. — Edokter • Talk • 14:21, 26 September 2007 (UTC)
You're probably wanting to use img.style.cssText...
What you're recommending is essentially what I tried in the code immediately above this section. It puts all the CSS, including border information, into an outer span and then removes CSS from the image.
It is indeed similair to what you did, but with the difference that the span is only created for those image that need it. The 'Standards complient' code still has a problem with |border (but not with |thumb); the outerspan somehow does nog get the border attribute assigned. Probably the same problem I have with border being undifined somehow. — Edokter • Talk • 18:36, 26 September 2007 (UTC)
Absolutely. But exploring it in the IE dev toolbar shows that the |border img does not have the border atrtributes it should inherit form .thumbborder. — Edokter • Talk • 18:48, 26 September 2007 (UTC)
Can we collaborate online somewhere, IRC maybe? I'm getting nowhere. It is pretty frustrating being full of ideas, but just not being able to pinpoint a problem. — Edokter • Talk • 19:39, 26 September 2007 (UTC)
Just a note on your assumption above — "pages with lots of images" usually do have borders. Specifically, pages with hundreds of flag icons (e.g. List of countries) all use flag templates that put borders around every image. Also note that these icons are also extremely sensitive to distortion (i.e. even one pixel makes a noticable difference), so it is very important to maintain the aspect ratio and not use the "scale" option. Andrwsc19:45, 26 September 2007 (UTC)
Noted. That's why I'm trying to get my solution above to work, but my knowledge of javascript fails me. I feel I'm on the verge of a breakthrough... I just need a little help. — Edokter • Talk • 19:49, 26 September 2007 (UTC)
I need second eyes... I MUST be overlooking something stupid! Please look at [6]. Why is img.style.cssText empty/undifened, and thus are the broders not showing??? (Test here.) — Edokter • Talk • 22:49, 26 September 2007 (UTC)
Because that information is defined in the thumborder class, not in the image's CSS text. You can use img.currentStyle to get at that information, but the code should really transfer the class information from the img element to the span used for styling.
Incidentally, did you have any problems getting the IE developer toolbar to install? It wouldn't work for me when I tried it earlier. In Firefox I can just use Firebug, but that's of little help here. —Remember the dot(talk)00:37, 27 September 2007 (UTC)
Never mind; you are receiving the thumbborder class, because it is in common.css; I didn;t have it in my common.css on Commons. However, you should no longer need to... I actually got my code to work! No distortions, showing borders, clickable, perfectly alligned, and no external .thumbborder class needed. The only thing to test are imagemaps, which I expect should work because it always uses an <img> tag to show the image, and the containing span should pass all events. Please test my code.
OK, that's weird. They're there, but their clientHeight and clientWidth = 1 instead of the image dimensions, meaning it takes the transparent image's size. Hold on... — Edokter • Talk • 02:27, 27 September 2007 (UTC)
Imagemaps also work perfectly! So we can !img.useMap So that leaves !img.onclick. What does that filter out and where can I test this? If the editing toolbar uses .onclick... then that is working as well. — Edokter • Talk • 12:39, 27 September 2007 (UTC)
!img.onclick prevents the script from running on the edit toolbar buttons. Code that doesn't remove the original img element shouldn't need this filter.
I don't even see the jump on Commons, and the page layout does not suffer in any way. Besides, I think it's a side effect of the filter kicking in and the browser adjusting it's layout. If that is the only problem, I'd recommend making this code live. It solves more problem then they current code causes. — Edokter • Talk • 17:37, 27 September 2007 (UTC)
You might not be seeing the jump because Commons:User:Edokter/monobook.js still uses the "addOnloadHook" function, which was removed from the code here because it caused some very bad speed issues. It causes IE6 to load all the images on the page before it displays it, which is very bad.
Then we have a difference of opinion. I pose that the difference in layout is less compared the difference in layout between IE and Firefox, and that it does not damage the layout in anyway, yet offers more functionality and speed then the current code. I think IE6 users benefit more with the added functionality then the 1px jump that does not harm the layout in anyway; the images are not distorted; the only visible effect is a 1px vertical margin drop in images with borders, and like you said, it can never be perfect. — Edokter • Talk • 19:50, 27 September 2007 (UTC)
I request that the PngFix() function be changed to use the code at #More standards-compliant version. The function will still behave the same way, but it will encourage using standards-compliant code. In other words, it will set a good example for others who wish to add JavaScript to MediaWiki:Common.js or their personal JavaScript files. It also may decrease page load time.
Done Though only for the sake of 'being compliant'. I still regard that code as broken because imagemaps don't work, so if I find an solution for the jump, which I think is not even a problem, I'll put my code in immediately. Of course, you may want to pitch in; the jump is related to the font-size and the span's margin being off by 1px. Ultimately, we should avoid using the inner span for the image; it breaks too much functionality. — Edokter • Talk • 08:53, 28 September 2007 (UTC)
Thanks! But what functionality does my code break? I thought I put in sufficient checks to make it not run in cases where it won't work right. The thing that's really doing the "breaking" here is Internet Explorer 6. You can see why I don't recommend it.
It doesnt break anything perse, but it doesn't display all PNG as transparent, I consider that broken. I'll continue working on my code. Why don't you hop over to commons:User talk:Edokter/pngtest where we can discuss without filling up this page? — Edokter • Talk • 18:20, 28 September 2007 (UTC)
Javascript issue with collapsible tables
{{editprotected}}
There is an issue where an incorrectly formatted collapsible table causes a JS error. That doesn't look like much of a problem, but it also means that all JS that should be run after this specific function stops dead in its tracks.
The problem is in function createCollapseButtons(). ButtonLink.style.color = Tables[i].getElementsByTagName( "tr" )[0].getElementsByTagName( "th" )[0].style.color; Before this is run, there should be if checks that verify if there are any tr and th elements at all in the table. --TheDJ (talk • contribs) 22:12, 14 September 2007 (UTC)
Just below it is actually an if ( header ) check. If that is move up to the top of this loop, before the button and links are created, then the issue is solved. Seems the easiest approach in this case. --TheDJ (talk • contribs) 22:25, 14 September 2007 (UTC)
