MediaWiki talk:Common.js/Archive Oct 2007

message: 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. THEPROMENADER 07:58, 27 August 2007 (UTC)
replies: text: I am semi-responsible for this, but, those need to be es.  I'll try to convert them.  shudder! ←BenB4 18:32, 31 August 2007 (UTC)
thread_title:  "Navframe" boxes no longer collapsing 

message: See this diff. Why isn't the code at the bottom properly handled, causing the message to appear at the top of the page? —Ruud 16:39, 28 August 2007 (UTC)
replies: text: No idea, but it's only on diffs on MediaWiki:Common.js. —METS501 (talk) 16:41, 28 August 2007 (UTC)
replies: text: 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 Smotrov 17:06, 28 August 2007 (UTC)
replies: text:  Yeah, but the  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? —Ruud 17:14, 28 August 2007 (UTC)
replies: text: 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  Mediawiki tag (which is not the same as HTML <pre> tag). I'm not sure what you mean about  tags ∴ Alex Smotrov 17:45, 28 August 2007 (UTC)
replies: text:  Appart from -tags Common.js also contains -tags. Those are just outputted as preformatted text on the diff pages, not unescaped HTML like the -tags are. Apparently some developer went to the trouble of handling the two differently, I however, fail to see why. —Ruud 21:41, 28 August 2007 (UTC)

text: This is a bug, insofar as any display hacks normally used on .js/.css pages should certainly be applied to diffs as well.  Please file a report on bugzilla.  —Ilmari Karonen (talk) 17:43, 3 September 2007 (UTC)
thread_title:  code on diff pages 

message: 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.
Add this line:
ButtonLink.style.color = Tables[i].getElementsByTagName( "tr" )[0].getElementsByTagName( "th" )[0].style.color;
Directly BEFORE these lines in function createCollapseButtons():
ButtonLink.setAttribute( "id", "collapseButton" + tableIndex );
ButtonLink.setAttribute( "href", "javascript:XcollapseTable(" + tableIndex + ");" );
ButtonLink.appendChild( ButtonText );
Thanks, --CapitalR 02:36, 3 September 2007 (UTC)
replies: text: Done. Cheers. --MZMcBride 02:42, 3 September 2007 (UTC)
thread_title:  Add code to automatically set collabsible table's show/hide button color 

message: 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 ). --MZMcBride 20:33, 3 September 2007 (UTC)
replies: text: Thats due to caching. It's expected and unavoidable when we change anon-notice methods. It will go away on its own.. or you can purge the page. This is explained several times on MediaWiki talk:Anonnotice--Gmaxwell 22:33, 3 September 2007 (UTC)
replies: text: Yeah, that seems to have fixed it. Cheers. --MZMcBride 23:12, 3 September 2007 (UTC)
thread_title:  Bug 

message: 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:
Then hop over to Mediawiki:Common.css and add the following:
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)
replies: text: Done. Cheers. --MZMcBride 04:28, 10 September 2007 (UTC)

text: 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)
replies: text: I see another problem now too.  The alt attribute is truncated if it has a single quote character, as in the case of  ( - should be Flag of the People's Republic of China) and  ).  Andrwsc 16:02, 10 September 2007 (UTC)
replies: text: That should be easy to fix, but I don't have time to work on it right now. —Remember the dot (talk) 16:21, 10 September 2007 (UTC)

text: Again, I'll work on it when I can. I'll probably be able to get the code all cleaned up (I admit it's messy) and bug-free within 24 hours. —Remember the dot (talk) 20:54, 10 September 2007 (UTC)

text: Yes, with the mixing of " and ' , I'm truly surprised the entire site didn't collapse. : - ) --MZMcBride 21:27, 10 September 2007 (UTC)

text: 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)
thread_title:  Tada! 

message: 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.
—Remember the dot (talk) 02:21, 11 September 2007 (UTC)
replies: text: Done. Cheers. --MZMcBride 02:30, 11 September 2007 (UTC)
replies: text: Thanks! —Remember the dot (talk) 03:04, 11 September 2007 (UTC)
replies: text: And thank you! Everything seems to be working now (even on Commons).  — Edokter • Talk •  08:30, 11 September 2007 (UTC)

text: This is causing a problem with Wikipedia:Route diagram template (see Wikipedia talk:Route diagram template#Display issue with bridge icons), due to U-umlaut being used in some German-sourced images. --Dr Greg 17:23, 11 September 2007 (UTC)
replies: text: Hopefully I'll be able to investigate this issue and find a fix within 24 hours. Please be patient. —Remember the dot (talk) 18:40, 11 September 2007 (UTC)
replies: text: 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)

text: 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.  Andrwsc 00:52, 12 September 2007 (UTC)
replies: text: ☑ (which by now I found out is (U+2611) isn't latin-1; it's part of the "Miscellaneous Symbols" block see . 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)
replies: text: 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.  Andrwsc 19:14, 13 September 2007 (UTC)
replies: text: 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)
replies: text: I think we are in "violent agreement" with each other!  Andrwsc 01:19, 14 September 2007 (UTC)
thread_title:  Code cleanup as requested 

message: The fix for the Unicode image naming problem is actually quite simple. I've debugged it on Commons and (with the help of , kudos to Edokter) found a fix. Just change
+ img.src +
to
+ encodeURI(img.src) +
And change "Tweaked 11 Sep 2007" to "Tweaked 12 Sep 2007", or remove the date entirely if you like. —Remember the dot (talk) 02:44, 12 September 2007 (UTC)
replies: text: Done. Bit of a backlog in CAT:PER; it was good that you let me know. Cheers. --MZMcBride 03:41, 12 September 2007 (UTC)

text: 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)
replies: text: Please take your time, no rush... Happy to help testing though (I can test on commons and nl.wiki).  — Edokter • Talk •  19:20, 13 September 2007 (UTC)
thread_title:  Bugfix part 2 

message: 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)
thread_title:  Other methods 

message: I went through and optimized the code to reduce unneccessary processing. Give this a try:
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)
replies: text:  Done —METS501 (talk) 16:38, 14 September 2007 (UTC)
replies: text: Thank you! —Remember the dot (talk) 17:22, 14 September 2007 (UTC)

text: Is there a big fat list of PNG/SVGs on Commons somewhere, something like Wikipedia:Route diagram template? Looks good so far, but can't test here (and that route diagram page is the utimate test page for this script.)  — Edokter • Talk •  11:20, 14 September 2007 (UTC)
replies: text: Commons:Category:Diagrams has a nice collection of PNG and SVG images. —Remember the dot (talk) 20:34, 14 September 2007 (UTC)

text:  Done —METS501 (talk) 23:03, 14 September 2007 (UTC)

text: 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.  Andrwsc 22:08, 14 September 2007 (UTC)
replies: text: 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)

text: That's odd...I wonder if the bug described in the section below is related. —Remember the dot (talk) 23:23, 14 September 2007 (UTC)

text: Interestingly, if you click [edit] on one of those collapsible sections, and then click "Show preview", it works just fine.  —Remember the dot (talk) 23:32, 14 September 2007 (UTC)
replies: text: 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)
replies: text: 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)
thread_title:  Optimized code 

message: In order to resolve the issues that the previous code caused, I request that the PngFix function be changed as follows:
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)
replies: text: Looks good to me.  I'm not going to make the change, since I don't have IE to test it with, but I hope someone else can take care of this.  —Ilmari Karonen (talk) 19:16, 15 September 2007 (UTC)

text: 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)
replies: text: It's not truly broken, it just is missing part of the border. But, all the same, I'll disable the editprotected request until this is resolved. —Remember the dot (talk) 22:35, 15 September 2007 (UTC)
replies: text: 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)
replies: text: 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)
thread_title:  New approach, far less problems 

message: 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.
—Remember the dot (talk) 23:57, 15 September 2007 (UTC)
thread_title:  Improved though not revolutionized 

message: 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)
replies: text: 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)
replies: text:   Thanks for the report.  —Ilmari Karonen (talk) 19:13, 15 September 2007 (UTC)
thread_title:  Javascript issue with collapsible tables 

message: addOnloadHook(function () {
  if( wgCanonicalNamespace == "Template" && document.getElementById("doc_editlinks") ) {
    var editsection = document.getElementById("doc_editlinks");
    editsection.innerHTML = '[<a href="' + wgServer + '/wiki/ + wgPageName + '/doc" title="View the template documentation for this page">view</a>]' + " " + '[<a href="'+ wgServer + wgScript + '?title=' + wgPageName + '/doc&action=edit" title="Edit the template documentation for this page">edit</a>]';
  }
});
This script turns the "[edit]" link into an href (such as the one that allows editing of a section on a page). Would anyone be opposed to its addition to MediaWiki:Common.js? — talk 14:35, 30 September 2007 (UTC)
replies: text: Huh? What do you think the "[edit]" link does now? Mike Dillon 15:21, 30 September 2007 (UTC)

text: Hardcoding text messages within javascript is not desireable; that is why MediaWiki has Special:Allmessages. Browser complains about a missing ";" too.  — Edokter • Talk •  18:47, 30 September 2007 (UTC)
thread_title:  <code>&#123;{template doc}}</code> modifier script