MediaWiki talk:Common.js/Archive 14

From Wikipedia, the free encyclopedia

Archive This is an archive of past discussions. 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.

Contents

Template:Link GA

I'd like to add the support for a {{Link GA}} template, similar to {{Link FA}}. All this has already been implemented and tested on the French wiki. (fr:Modèle:Lien BA) I currently have a bot overthere that is adding the template, and I wanted to do the same here. An example of a GA link in interwikis can be found overthere : fr:Pi.

In fact you would need to alter LinkFA() into

function LinkFAorGA() 
{
     if ( document.getElementById( "p-lang" ) ) {
         var InterwikiLinks = document.getElementById( "p-lang" ).getElementsByTagName( "li" );
 
         for ( var i = 0; i < InterwikiLinks.length; i++ ) {
             if ( document.getElementById( InterwikiLinks[i].className + "-fa" ) ) {
                 InterwikiLinks[i].className += " FA"
                 InterwikiLinks[i].title = "This is a featured article in another language.";
             }
             else if ( document.getElementById( InterwikiLinks[i].className + "-ga" ) ) {
                 InterwikiLinks[i].className += " GA"
                 InterwikiLinks[i].title = "This is a good article in another language.";
             }
         }
     }
}
 
addOnloadHook( LinkFAorGA );

and add into Monobook.css

li.GA {
    list-style-image: url("http://upload.wikimedia.org/wikipedia/fr/8/86/Icone_BA.png");
}

(You might need to find another link in en: to that very same image, thought)

Thanks,

NicDumZ ~ 17:46, 20 December 2007 (UTC)

The template in question was deleted after discussion at Wikipedia:Templates for deletion/Log/2007 October 4#Template:Link GA, and I don't think MediaWiki_talk:Common.js is a good place for a new discussion whether we need this template at all ∴ AlexSm 18:14, 20 December 2007 (UTC)
Yeah, I know, it was deleted because the function was not supported in the monobook and because it was adding wieird categories on the articles itself: "Category:Good Article in French", etc... It was stupid. Now that this is working on fr:, I'm asking this again.
And... Where should I ask if not here ? NicDumZ ~ 18:23, 20 December 2007 (UTC)
Make a proposal here. Cheers. --MZMcBride (talk) 01:00, 21 December 2007 (UTC)
This idea has been rejected a few times already. I think the discussions should be somewhere in the archives of this talk page. —Ruud 09:31, 21 December 2007 (UTC)

Edit made without consensus

{{editprotected}}

Please undo this recent edit. This edit does not have consensus. The TeX markup was not intended to be displayed in the tooltips of images, and if we are going to make a change to display the markup in image tooltips, the change should be made for all browsers, not just Internet Explorer. —Remember the dot (talk) 21:26, 29 December 2007 (UTC)

I restored Internet Explorer's default behaviour in this respect. The tooltips were showing before PngFix, and now they do again, as expected. Just because they are not supposed to show, does not mean we should not respect IE's default behaviour. IE shows alt tags as tooltips, and is not a matter that shoud be "fixed", even if it "breaks" HTML standards. — Edokter • Talk • 21:41, 29 December 2007 (UTC)
If IE has quirky behavior and we can't fix it, that's one thing. But where IE has quirky behavior, and it's fixable (and it was fixed), that's another. Your change actually decreases performance on Internet Explorer for no other reason than to re-introduce one of Internet Explorer's quirks. If you think that we should make the TeX markup show up in tooltips, then that change needs to be made for all browsers, not just Internet Explorer. —Remember the dot (talk) 21:49, 29 December 2007 (UTC)
Proposal
  • Change if (img.useMap) to if (img.useMap || img.className == "tex")
  • Take out outerSpan.title = img.title... Done.

img.title is always empty anyway. Also, the img.classname lookup seems to have no speed impact at all (probably because it is cached). — Edokter • Talk • 17:06, 30 December 2007 (UTC)

If you want to make the TeX markup show in the tooltips, make it appear there for users of all browsers, not just Internet Explorer. —Remember the dot (talk) 02:25, 31 December 2007 (UTC)
You have a point about outerSpan.title = img.title... and I wouldn't mind if you removed this statement. —Remember the dot (talk) 02:26, 31 December 2007 (UTC)
The script does not touch any other browser, so I can't make the tooltips appear in any other browser here; that requires a change in TeX or MediaWiki. But the change would restore IE default behaviour. — Edokter • Talk • 12:21, 31 December 2007 (UTC)
Make another script that copies TeX alt attributes into TeX title attributes, and do not restrict that script to any one browser. —Remember the dot (talk) 19:29, 31 December 2007 (UTC)
I'm not restricting anything; IE displays alt as tooltips, as it has always done (even Netscape did so). If you want other browsers to do the same, you're welcome to write s script that does so. — Edokter • Talk • 20:36, 1 January 2008 (UTC)
Thank you for altering common.js appropriately. Here is code you can use for displaying the alt attribute in the tooltip:
/* Use alt attribute as the tooltip text, for example with TeX-generated images.
   The MediaWiki software never adds title attributes to images anyway, so there is no danger of
   overwriting an existing tooltip. */

function useAltForTooltips()
{
    var documentImages = document.images
    
    for (var i = 0; i < documentImages.length; i++)
    {
        var img = documentImages[i]
        img.title = img.alt
    }
}

if (!window.useAltForTooltipsDisabled)
{
    window.addOnloadHook(useAltForTooltips)
}
I don't have a strong opinion on whether we should use this code or not, so you can do what you like. Just try to keep the experience consistent across all browsers. —Remember the dot (talk) 22:06, 1 January 2008 (UTC)
My intention was simply to restore IE's default behaviour, which I do not regard as a bug. If you want TeX-tooltips to display in other browsers as well, I suggest asking the community first (on WP:VPT) to see if non-IE users want the tooltips. In that case, a change should be made to TeX rather then add yet another script. I do intend to implement the other change listed above; that would at least speed up pages with TeX rendering. — Edokter • Talk • 22:46, 1 January 2008 (UTC)
Sure, go ahead and make the other change. As long as the squid servers don't kill themselves again it should be fine. And feel free to ask the community about whether or not TeX markup should show up in tooltips. The major issue that I have is making it show up in the tooltips only for Internet Explorer, which results in inconsistency between browsers. —Remember the dot (talk) 23:19, 1 January 2008 (UTC)
My point is just that it is an inconsistency that has always existed, and therefor not something that should be 'fixed'. People using IE expect certian behaviuour, users using ohter browser expect other behaviour. But I am dubbing over the squid issue... It does make me wonder why the standard monobook bullet doesn't kill the squids. — Edokter • Talk • 23:59, 1 January 2008 (UTC)
IE has all sorts of inconsistencies that have always existed that cause all sorts of problems. Just because it's always been there doesn't mean that it's worth keeping there. The casual user knows nothing of all this, of course. They might actually wonder why Wikipedia shows tooltips on TeX images in IE7 but not in IE6, Firefox, Opera, Safari, etc. The answer is that there's not a good way to keep IE7 from displaying them, but there is in the other browsers. But, if we decide that having those tooltips there is a good thing, then we can make the change, and make it for all browsers. —Remember the dot (talk) 20:40, 2 January 2008 (UTC)

class,IPA

The {{IPA}} template which is based on class.IPA forces Firefox to display the IPA correctly, but adding to a table class="IPA" or class="IPA wikitable", which are based on the same class, does not. Instead, it displays with Arial Unicode, which is defective in its IPA range. How do we fix this? kwami (talk) 07:06, 3 January 2008 (UTC)

The IPA class is never intended to be used directly; It should only be used by the several Unicode templates in order to display Unicode characters. — Edokter • Talk • 13:52, 3 January 2008 (UTC)
So are you saying it cannot work as a custom HTML class in tables? kwami (talk) 16:47, 3 January 2008 (UTC)
That is correct. — Edokter • Talk • 17:11, 3 January 2008 (UTC)
I was under impression that IPA class is here only to fix IE shortcomings. I wish someone could write a detailed help page on this topic ∴ AlexSm 01:36, 7 January 2008 (UTC)
There are two problems in FF: One, if you don't format all IPA with a specific font, you get the browser's default font for letters it covers, which often doesn't match and looks very unprofessional. Two, whenever the font includes replacement pairs, such as IPA tone letters or Indic akshara, a simple class="wikitable" table doesn't force them to combine. However, a class="wikitable" style="text-align:center" table displays them properly. I have no idea why the behavior is so odd, but suspect it's a bug in Wikipedia coding. kwami (talk) 02:02, 7 January 2008 (UTC)
I was able to compensate by adding ".IPA { font-family: Gentium, Charis SIL !important; }" to my monobook.css, but something like this should be automatic. kwami (talk) 19:42, 26 May 2008 (UTC)
The problem with decomposed ligatures and akshara was due to setting my prefs to justified text. Once I aligned it left, the issue disappeared. So there is a bug in the code. Is it possible to have proper ligature rendering and justified text? kwami (talk) 19:44, 26 May 2008 (UTC)

Hide "user page" link for anonymous users

{{editprotected}}

I proposed this at Wikipedia:Village pump (proposals)#Hide "user page" link for anonymous users and there were no serious objections, so I'd like to have this code added to the site-wide JavaScript. If this causes a revolt then just remove it. If people like it then we can ask the developers to provide a way to do this more elegantly through CSS.

/** Automatically hide "user page" link for anonymous users that do not have user pages
  * Created by Remember_the_dot
  */
 
function hideAnonUserPageLink()
{
    var userPageLink = document.getElementById("ca-nstab-user")
    if (!window.hideAnonUserPageLinkDisabled && userPageLink.className == "new")
    {
        document.getElementById("ca-nstab-user").style.visibility = "hidden"
    }
}
 
if (wgPageName.search(/^(User_talk:(?:(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.){3}(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?))$/) == 0)
{
    window.addOnloadHook(hideAnonUserPageLink)
}

I can also make a gadget to disable this behavior if there is demand for it. —Remember the dot (talk) 01:48, 4 January 2008 (UTC)

No please. Good suggestion, however, some of them have user pages. Also, this adds a few lines of code with no real net gain. Regards, Mercury 02:25, 4 January 2008 (UTC)
It would only hide links to nonexistant user pages. —Remember the dot (talk) 03:00, 4 January 2008 (UTC)
Not done. This code makes a change that is arguably deceptive; there's a standard that tabs exist, regardless of page existence, and adding this code would change that expected behavior. I also fear that it would lead to a lot of confusion among the community. In addition, there are legitimate reasons for wanting to post to an anonymous user's user page, and this code change would make it more difficult. It also adds more code to an already lengthy file, with little net gain, and very likely net losses. However, you're free of course to add it to your personal subpage. Also, it could be made into a gadget for users to choose to enable or not, however, the default should be off. Cheers. --MZMcBride (talk) 02:30, 4 January 2008 (UTC)
What are the legitimate reasons for putting anything on an IP user page? IP user pages are never linked to, in fact if you type "User:78.86.150.44" into the search box and hit "Go", it will take you to the contributions page. —Remember the dot (talk) 03:00, 4 January 2008 (UTC)
For one, it is common to place (shared) IP information and blocked sock templates on an IP's userpage, which would be hard to do if there is no tab. — Edokter • Talk • 12:15, 4 January 2008 (UTC)
That information is almost always given on the IP's talk page where people will see it. —Remember the dot (talk) 18:00, 4 January 2008 (UTC)

You can estimate how often IP user pages are used with about 200 searches like Special:Prefixindex/User:78.. It seems like not very often, most are redirects to talk pages. I agree that this kind of script is a hack and instead we need either a MediaWiki fix or a policy which would say "only use user_talk: for IPs" ∴ AlexSm 16:40, 4 January 2008 (UTC)

The idea was that if people liked the change, we could get the MediaWiki software to allow us to do this through CSS, which would be a much more elegant solution. I would much prefer CSS to JavaScript. —Remember the dot (talk) 18:00, 4 January 2008 (UTC)

If we could do this through CSS, and the CSS only changed the link's color from red to gray instead of removing it entirely, would you support the change? —Remember the dot (talk) 18:57, 4 January 2008 (UTC)

I've filed bug 12509 about doing this more elegantly with CSS. —Remember the dot (talk) 02:11, 5 January 2008 (UTC)

addDismissButton in Opera

I don't think addDismissButton() should continue after it finds out that the cookie is set to hide the message. There is no point to create [dismiss] link after that. Besides, for some reason this link is still visible in Opera (9.25) while the whole message is hidden (probably Opera's fault, but still...). In other words, we need a return immediately after watchlistMessage.style.display = "none" ∴ AlexSm 01:36, 7 January 2008 (UTC)

On subpages and tabs

Currently, when you're at a subpage, e.g., Template:Infobox Election/doc, the "discussion" tab links to the /doc talk page rather than the main talk page. I asked User:Splarka if there was a JavaScript way to fix this, and he wrote the code found below. It changes the tab to blue and links it to the main talk page if the tab is already non-existent. It's currently written to only work on /doc and /sandbox pages. Would there be any objections to implementing it site-wide? It would save a lot of unnecessary redirects. Improvements are, of course, welcome. Cheers. --MZMcBride (talk) 06:22, 7 January 2008 (UTC)

if(wgPageName.indexOf('/')!=-1 && (wgNamespaceNumber % 2)==0) addOnloadHook(redirSubpageTalk)
function redirSubpageTalk() {
  var redir = [
    /\/doc/i,
    /\/sandbox/i
  ]
  var talk = document.getElementById('ca-talk')
  if(talk.className.indexOf('new')==-1) return;
  var talka = talk.getElementsByTagName('a')[0];
  for(var i=0;i<redir.length;i++) {
    if(talka.href.search(redir[i])!=-1) { 
      talka.href = talka.href.replace(redir[i],'').replace(/action\=edit/i,'action=view');
      talk.className = '';
    }
  }
}
Wouldn't it be better to submit a bug report? (rather than link-munge) GracenotesT § 16:38, 7 January 2008 (UTC)
On second note, I'm not sure this is a good idea, given that it violates the principle of least astonishment – users shouldn't have to check the status bar to see where a user interface link leads. it would make a good user script, however. GracenotesT § 18:21, 7 January 2008 (UTC)
Yeah, I thought about that; however, the code stops if the /doc talk page actually exists, and I think it would be justifiable to do this if the result was easier accessibility. Currently, people are creating redirects, which simply seems kinda silly. --MZMcBride (talk) 21:31, 7 January 2008 (UTC)
Why is it silly? Creating redirects is the way in which redirection is meant to be handled in MediaWiki wikis, not with kludgy javascript. Adding the above code would be very annoying; I'd have to disable javascript on Wikipedia and manually copy the rest of the scripts from various different places into a local file and use that, which would be a lot of fuss – Gurch 22:10, 7 January 2008 (UTC)
It's silly because the pages are never going to be used for anything other than redirects to the target they should go to. And even if there is legitimate content, the script takes that into account and shuts down. Currently, most of the /doc talk subpages aren't redirects and the interface is just a little clunkier. Instead of being able to just click the tab and go to the page that they intended, users either have to create redirects or go back and then go to the talk page. Meh. I'll probably just enable it for myself; let them have red tabs. --MZMcBride (talk) 02:51, 8 January 2008 (UTC)
That is proof only that the /doc subpage system was a stupid idea in the first place. There was nothing wrong with having the documentation on the discussion page – and avoiding all that silly meta-templating on the template page itself – but it just had to be changed, didn't it? – Gurch 18:34, 8 January 2008 (UTC)
If people are competent enough to edit doc pages, why would they ever click the red link or think a redirect would be intuitive rather than misplaced? That's like making a redirect in articlespace to correspond with every talk archive. A trivial solution would be to add a link to the talk page to {{Documentation}}, if it's likely to be noticed. –Pomte 00:52, 9 January 2008 (UTC)

Problems with collapsible shells and older safari browsers

Hi - I've just realised that the reason so many navigation templates and WikiProject banners seem to have disappeared from Wikipedia in the last few months is that they haven't gone - I've just been unable to see them. With the combination of browser and platform I (and presumably other) WP editors use (Mac OS 10.2.8/ Safari 1.0.3) the shell renders all templates within it as thin, unexpandable lines. Is there any way to fix this so that I don't have to physically edit the article to see what templates are on it? There's some discussion of this already at Template_talk:WikiProjectBannerShell, which is where I first raised this issue, but the suggestion there is that this is the place to come. As an example of what I mean, here's how the top of Talk:Algeria looks to me:

Image:Shellprob.jpg

User:Anomie suggests that: " If that is the case, I suspect the problem is on line 126 of the current version as I remember hearing that particularly old versions of Safari do not correctly support the table "rows" collection."

Any possible way of fixing the problem? Grutness...wha? 23:21, 18 January 2008 (UTC)

{{editprotected}}
We've done some experimentation, and it seems I was correct as overriding the function in Grutness's monobook.js with a fixed version has fixed the problem. Please change line 126 from var Rows = Table.rows; to var Rows = Table.getElementsByTagName( "tr" );. Thanks. Anomie⚔ 13:33, 19 January 2008 (UTC)
Has this been tested that it does not break other browsers? — Edokter • Talk • 14:35, 19 January 2008 (UTC)
The other function implementing this feature, createCollapseButtons, uses getElementsByTagName to get the list of table rows, so if this would break anything then it is already broken. I suppose to be 100% safe you should use lower-case "tr" instead of "TR"; I have edited the request accordingly. Anomie⚔ 14:46, 19 January 2008 (UTC)
Y Done — Edokter • Talk • 15:02, 19 January 2008 (UTC)
D'oh! I see you rightly reverted it as it caused unrelated problems. Anomie⚔ 15:12, 19 January 2008 (UTC)

I have had to revert this change, unfortunately. It broke functionality in nested tables in that they automatically expanded (and still showing the [show] link) when the main table is expanded. This needs more testing. — Edokter • Talk • 15:12, 19 January 2008 (UTC)

Ok, I have another attempt at User:Anomie/Sandbox.js. The code there can be copied into a monobook.js for testing, I'm not going to be so hasty this time ;) So far, it seems to work for Grutness in the old Safari version and me in Firefox 2.0.0.11. Anomie⚔ 03:54, 20 January 2008 (UTC)

smaxage=0

Due to persistent caching of user/site scripts and stylesheets, what do you think of temporarily modifying the following two lines from importScript and importStylesheet?

+ '&action=raw&ctype=text/javascript';

+ '&action=raw&ctype=text/css";'

to include &smaxage=0 so as to reduce the server-side cache to as low a number as possible? Eg:

+ '&action=raw&smaxage=0&ctype=text/javascript';

+ '&action=raw&smaxage=0&ctype=text/css";'

Notes:

  • In practice, this still seems to take up to 5 minutes.
  • This is not a drastic change or server bombing, client side caching is still up to 31 days by default.
  • If the devs don't like it, they can fix the bugs hampering meaningful script development! Grr, arg.

Please reach consensus before implementing (if at all?). An implement/revert/implement/revert battle over this, coupled with the caching bugs, would be worse than no action taken at all. --Splarka (rant) 05:27, 21 January 2008 (UTC)

r27456 --Splarka (rant) 06:15, 22 January 2008 (UTC)
What exactly did that change do? Will I have caching problems now when I try to rewrite and debug a script? —Remember the dot (talk) 18:14, 22 January 2008 (UTC)
I didn't analyze that PHP change, but I do have caching problems when developing scripts for WikiMedia projects. Despite purging, clearing my local cache, and forcing reloads, it takes currently between 5 to 10 minutes until changes are seen. This is behavior that I didn't see formerly. If I understand Splarka's suggestion right, setting maxage to zero should resolve this by forcing the server to serve always the latest version of a script, not some cached one. Lupo 07:23, 23 January 2008 (UTC)
Followup: A dev has disabled the cache server hack that was ignoring a "Pragma: No-cache" from the browsers. This apparently makes it possible to [reload] a page and re-request new raw CSS/JS. With some minimum testing it seems to work again (for now). --Splarka (rant) 08:02, 1 February 2008 (UTC)

import*() better?

A secondary request is to have these functions able to import scripts/styles from elsewhere, for example:

  • importScript('User:Foo.js') would grab the page as normal
  • importScript('http://en.wikipedia.org/w/index.php?title=User:Zocky/SearchBox.js&action=raw&ctype=text/javascript&dontcountme=s') would see 'http:' and load the path as absolute.
  • importScript('file:///c:/foo.bar.js','mediawiki') would see the local path and load it as absolute.

This would only take a quick if() block around the URL generator, eg for importScript something like... (the css version would be similar):

if(page.indexOf('http://') == 0 || page.indexOf('https://') == 0 || page.indexOf('file://') == 0) {
         var url = page;
     } else {
         var url = wgScript + '?title=' + encodeURIComponent( page.replace( / /g, '_' ) )
             + '&action=raw&ctype=text/javascript';
     }

Note: You may be tempted to ask for an tertiary interwiki feature, eg to [[m:User:Foo/bar.js]] but this would be... very hard to implement, as well as support, while the above modification would be relatively easy if done properly.

Thoughts? --Splarka (rant) 05:27, 21 January 2008 (UTC)

One potential issue is that people might grab script files off other sites, when really everything should be hosted on Wikimedia servers. I think the API might be able to enable interwiki imports. A quick Ajax request to the API to grab the URL (no more than a kilobyte or two round trip), and off you go. But overall, it might be more trouble than it's worth. —Remember the dot (talk) 06:17, 21 January 2008 (UTC)
Well, the problem of people trying to load JS from external sites can be solved easily enough by just allowing the "absolute path" import only if the server is *.wikipedia.org or *.wikimedia.org. Could even add the "&action=raw&ctype=text/javascript&dontcountme=s" part automatically. Lupo 07:33, 21 January 2008 (UTC)
Well, anyone can import local or remote scripts in their user js already, with a document.write or function similar to importScript(). Perhaps it could just be limited to logged in users? ... if(wgUserName) --Splarka (rant) 08:13, 21 January 2008 (UTC)

I have made versions of import* that do this for myself so that I can test them: See my diff. I agree that there is a risk for increased usage of external scripts, but I'm not sure wether that is a real problem. It is already happening with some of our most profound scripts (Lupin's tools, mini atlas, and CH2 all use commons and local servers for scripts). I don't really see the added danger, but; we could check for something like if(page.indexOf( wgServer ) == 0 || page.indexOf( 'http://meta.wikimedia.org') ==0 || page.indexOf('http://commons.wikimedia.org') ==0 || page.indexOf('file://') == 0) which is probably quicker than hitting the API with an ajaxreq. and still suit most of our problems. Lastly, perhaps its about time we re-discuss including scripts from other users. The Gadgets are a good first step, and I wouldn't want to loose the current ability to load scripts from other users because its just too damn easy, but I was thinking that perhaps having a bot look at our .js pages for any URL changes might be a good idea to prevent issues. --TheDJ (talk • contribs) 16:20, 21 February 2008 (UTC)

Problem with importStylesheet on Internet Explorer

{{edit protected}}

I mainly use Firefox, but I write some javascript that I want IE users to be able to use too. With Internet Explorer 7, I can't do appendChild on a STYLE element, nor can I set the innerHTML (both gives me errors). Thus, the importStylesheet() function here does not work with IE7 (though it does work fine with Firefox, Opera, and Safari). Instead, IE can use the document.createStyleSheet() function. -Pan Sola (talk) 09:31, 27 January 2008 (UTC)

This is a known issue yes. Adding if (document.createStyleSheet) document.createStyleSheet( theurl ); else { our current code } should take care of it according to various websources.... --TheDJ (talk • contribs) 14:17, 27 January 2008 (UTC)
There are also other ways to fix this for IE, like using cssText property, or creating <link> element (instead of <style> with @import), but I agree that document.createStyleSheet seems to be the best option ∴ AlexSm 14:27, 27 January 2008 (UTC)

Is there a specific edit that needs to be done? If not, please do not use the editprotected template as a general call for help. — Edokter • Talk • 15:15, 27 January 2008 (UTC)

Sorry I wasn't clear. I would like to advocate for the importStylesheet() function defined here to incorporate the IE check and calls document.createStyleSheet() from within, so that other javascripts needing to import stylesheets does not have to deal with the browser detection. Alternately, if for some reason importStyle() should not be modified to work on Internet Explorer, then I would advocate a note in the comments for the function here warning people that it will not work on Internet Explorer. -Pan Sola (talk) 21:23, 27 January 2008 (UTC)

Here is the diff that would do this. --TheDJ (talk • contribs) 22:10, 27 January 2008 (UTC)

Hmm, the {{edit protected}} says it's for requesting immediate edit. Should I use it if I believe the edit should be made but without any urgency? -Pan Sola (talk) 20:37, 31 January 2008 (UTC)
It's a good question, perhaps the template should be able to be used to get admin attention about a request, even if a clear edit proposal is finish. →AzaToth 20:52, 31 January 2008 (UTC)

See also #import.2A.28.29_better.3F, but this createStylesheet() implementation is currently active in my private implementation of the import*() functions. --TheDJ (talk • contribs) 16:22, 21 February 2008 (UTC)

Big performance improvement

{{editprotected}}

It's been suggested before that we factor out all the IE fixes, but nobody actually took the time to do it. Were this done, we would see two improvements:

  1. Those not using IE (who consequently do not need the IE scripts) would not have to waste time downloading them
  2. Only one check would need to be made to see whether the browser is IE or not

So, I went through and came up with the code necessary to do it. The scripts will all continue to work as before, but users will see an improvement in page load time. Since this doesn't involve an appreciable change in behavior, we should be able to just go ahead and do it.

Please create MediaWiki:Common IE.js with:
Please create MediaWiki:Common IE6.js with:
And finally, change MediaWiki:Common.js to:

—Remember the dot (talk) 21:54, 2 February 2008 (UTC)

Section break

I don't know... it seems that relatively little IE-specific code (less then 7KB) is moved out of common.js, so I'm not convinced of the performance benefits. The file is cached locally and on the squids anyway. Plus it would further fragment all the javascript in MediaWiki. But we could consolidate all version checks into one function at the bottom, and load the rest from there. — Edokter • Talk • 22:37, 2 February 2008 (UTC)

I doubt it's a performance gain for IE users. IE supports special conditions, such as <!--[if IE X]>IE-version-X-specific tags<![endif]-->, that are much more efficient. In both IE and Firefox, JavaScript files must be downloaded before page content after it displays, and chaining JS file downloads like that could produce a delay of a couple of seconds before page display with fast connections. Submitting bug reports for files like this is a good idea. GracenotesT § 23:14, 2 February 2008 (UTC)

OK. I've disabled the {{editprotected}} request for now. Perhaps we could create a variable such as "isIE" instead to at least centralize the checks for Internet Explorer. —Remember the dot (talk) 23:20, 2 February 2008 (UTC)
bugzilla:12766. --Splarka (rant) 08:10, 3 February 2008 (UTC)

Optimization: call functions only when needed

Preamble: last night I was debugging my new little script, which sorts watchlist entries by namespace and then alphabetically. For some reason it did not work in IE6, I spent countless minutes rechecking my code, and finally created a loop to display all DOM nodes. Of course, what I found was a SPAN where I expected to see an IMG.

The question is: why do I need PngFix script in my watchlist, where all used images are 256-color and thus do not need transparency fix? Why do I also need Wikiminiatlas, collapsible Tables and Divs on all special pages?

Proposal: move all addOnloadHook() calls to the bottom of the file, after checking some basic conditions, mostly for the current namespace. This should make Wikipedia pages a bit faster to respond after loading. This should also allow to remove several existing checks that are right now inside the functions.

For an example please look at the bottom of ru:MediaWiki:Common.js where I implemented this approach a long time ago ∴ AlexSm 17:06, 6 February 2008 (UTC)

The proposal has some merit, except a PNG image can appear in any namespace. Begs the question though, why are you quering images on your watchlist, which doesn't have images? Or does your script display images inline? In any case, setting PngFixDisabled to True in your script should also fix the problem. — Edokter • Talk • 17:25, 6 February 2008 (UTC)
256-color PNGs should be used for system messages, even if only for IE6 users with JavaScript disabled. As for my script, with "Enhanced recent changes" the watchlist structure is a bit complex, and to find the end of the row you have to traverse the DOM nodes until you find IMG or SPAN#RCMxx; of course, now that I finally figured the problem, I could get around it, but I would rather tell IE6 users that my script doesn't work because of PngFix, which is doing something to watchlist it's not supposed to. Back to proposal: the main purpose is not to "fix my script" but rather to avoid running any scripts when they are not needed ∴ AlexSm 18:22, 6 February 2008 (UTC)
There's a better solution here. You could simply add "PngFixDisabled = true" to your script and include a modified PngFix function that meets your script's particular needs. Failing that, many of the people still using IE6 can upgrade to IE7 or use a different browser such as Firefox or Opera. —Remember the dot (talk) 18:39, 6 February 2008 (UTC)
1) This was already suggested above; 2) The proposal is not about fixing my script; 3) I don't see why do you insist on running PngFix in watchlist where it only slows things down ∴ AlexSm 19:45, 6 February 2008 (UTC)
I like your proposal for functions that only run in a specific namespace. However, it's possible to put transparent images on the watchlist via JavaScript where PngFix should get to them. As it stands, the PngFix script is very fast and flexible, being able to handle even unusual cases like this, and I don't want to diminish either of those qualities. —Remember the dot (talk) 19:53, 6 February 2008 (UTC)
Would it be possible to add a user-defined variable (similar to the one you can use to deactivate the whole script) that would allow individual users to decide whether the script should run on pages such as watchlists? This makes more sense to me than either method of running the script on every page or preventing it from ever running on certain pages, and this way, because most visitors will never see a watchlist with a PNG image in it, those who consider it important enough can activate it via their Common.js. —Dinoguy1000 21:46, 7 February 2008 (UTC)
I realize that the purpose of your complaint above isn't just to "fix my script", but I'd just like to note that, for parsing the extended-mode watchlist (or recentchanges, for that matter), it's probably better to look for the BR elements at the end of each line rather than the IMG elements at the beginning. See User:Ilmari Karonen/watchfilter.js for an (unfortunately rather sparsely commented) example of a script that works on both watchlist variants; look in particular for the case marked with "// enhanced mode". —Ilmari Karonen (talk) 21:23, 8 February 2008 (UTC)
Not always: I answered in details on User talk:Ilmari Karonen/watchfilter.js. / AlexSm 16:39, 11 February 2008 (UTC)

Can't get it to work

I've copied the appropriate code to my wiki, but I cannot get collapsible tables to work. Ideas? Note that my system doesn't have a common.js file, so I just added it and put it under mediawiki\skins\common.

Any assistance is appreciated. Thanks Timneu22 (talk) 13:31, 11 February 2008 (UTC)

Did you also copy the relevant collapsible class from common.css? — Edokter • Talk • 15:22, 11 February 2008 (UTC)
"Collapsible" class does not have any extra CSS. Even if it did (like NavFrame), CSS has nothing to do with the collapsing functionality. Timneu22: please use Opera or Firefox, open error console and check for JavaScript errors. It;s possible e.g. you did not copy required hasClass() function / AlexSm 16:39, 11 February 2008 (UTC)
Sorry (and don't hurt me!), but I only have IE. How can I tell if there are errors? Also, I'm not sure how it will "just work" by creating this file:
  1. Common.js didn't exist
  2. I added it to mediawiki\skins\common
  3. How does any skin know to use it? I cannot imagine it will "just work" without me doing something else.
Thanks again Timneu22 (talk) 00:16, 12 February 2008 (UTC)

Sorry for some stupidity, I see that I needed to add this to my own MediaWiki:Common.js page. Done.

However, I'm having a problem now, where [hide] shows twice:

----------------------------------------------
-      Some title            [hide]   [hide] -
----------------------------------------------

Ideas? Thanks AGAIN! Timneu22 (talk) 11:59, 12 February 2008 (UTC)

Finally, looks like I got it right. I commented out the following (because it is unneeded on my wiki):
function sysopFunctions() {
        if ( wgUserGroups && !window.disableSysopJS ) {
                for ( var g = 0; g < wgUserGroups.length; ++g ) {
                        if ( wgUserGroups[g] == "sysop" ) {
                                importScript( "MediaWiki:Sysop.js" );
                                break;
                        }
                }
        }
}

addOnloadHook( sysopFunctions );

That function which you commented out isn't actually part of the collapsible tables code (it actually enables a seperate JS file for sysops only), and can be safely deleted. —Dinoguy1000 18:14, 13 February 2008 (UTC)

Yeah, I knew it had nothing to do with tables. I just commented (as opposed to deleting) for the possibility that I will need it in the future. Thank you for your comment! I'm glad everything is working for my wiki! :) Timneu22 (talk) 23:57, 13 February 2008 (UTC)

I Can't get it to work, either

I am also having trouble getting common.js to give me a collapsible table.

I have copied the entire source of the common.js page into my own Mediawiki:Common.js area. I am using MediaWiki 1.6.7, could that have something to do with it? I am uncertain what to do, and would appreciate any assistance. Damian - 61.8.101.1 (talk) —Preceding comment was added at 07:09, 20 February 2008 (UTC)

Hello, the reason MediaWiki:Common.js isn't working on your wiki is because it wasn't enabled in MediaWiki until version 1.10. Unless you care to upgrade your wiki software, you'll have to make do with MediaWiki:Monobook.js. —Dinoguy1000 18:41, 20 February 2008 (UTC)
I don't believe that last statement is true. I'm on 1.9.3 and it works (at least the collapsible tables part that I need). Timneu22 (talk) 21:45, 24 February 2008 (UTC)

Can I get it to work with MediaWiki: 1.6.10 ?? Andrew —Preceding unsigned comment added by 124.186.76.93 (talk) 16:34, 5 May 2008 (UTC)

line-spacing with sub & sup

As discussed on MediaWiki talk:Common.css. It is proposed (final idea by AlexSm) to add the following:

/* Function to add simple style blocks. */
/* Use sparsely and larger blocks of CSS should be loaded by importStylesheet() */
function appendCSS(text){
 var s = document.createElement('style');
 s.setAttribute('type', 'text/css');
 if (s.styleSheet)
  s.styleSheet.cssText = text; //IE
 else
  s.appendChild(document.createTextNode(text));
 document.getElementsByTagName('head')[0].appendChild(s);
 return s;
}
 
/* This avoids breaking the linespacing when using sup and sub elements */
/* No solution for IE currently exists */
/* See also http://en.wikipedia.org/w/index.php?title=MediaWiki_talk:Common.css&oldid=193038464#line-spacing_with_sub_.26_sup */
if( is_opera || is_safari || is_gecko) {
    appendCSS('sup, sub {line-height:0;}');
}

We all wish there was a better way, but alternatives do not seem to exist. --TheDJ (talk • contribs) 14:52, 21 February 2008 (UTC)

It has not been shown that the line-height:0 causes a problem on IE - the problem that was observed still occurs if it is absent. —Random832 04:10, 24 February 2008 (UTC)

Seems to be resolved, per MediaWiki talk:Common.css#Space between paragraphs please (References), and specifically this change to MediaWiki:Common.css. Thanks. -- Quiddity (talk) 18:44, 8 April 2008 (UTC)

Other Wikis - unwanted messages

Hello, I have the "meetup message" appearing on my own wiki:

The next New York City meetup is Sunday March 16th.
You're invited! [hide]

What part of Common.js do I need to comment so these always go away? Thank you! Timneu22 (talk) 21:48, 24 February 2008 (UTC)

Look for "Geo-targeted watchlist notice" and disable the function underneath it. — Edokter • Talk • 21:53, 24 February 2008 (UTC)
Indeed... thanks Timneu22 (talk) 21:59, 24 February 2008 (UTC)

"Show/Hide" link div width on collapsible tables

Something that recently struck me is how excessive the width on the div element for the show/hide link in collapsible tables is. From what I've seen, 6 em is actually far more than is needed in most cases, and I would like to see it cut. However, at this point there are a lot of templates that use it under the assumption that it will be 6em wide, so an outright change would be unacceptable. Therefore, I was wondering if it would be possible to make the exact width configurable, with the default remaining 6em. However, I'm not sure how it might be implemented (except maybe by adding another name to the "class" attribute), and I'd like to hear others' opinions on it as well. —Dinoguy1000 18:13, 26 March 2008 (UTC)

Yes, it could easily be reduced to 4em, but it would have to be done in conjunction with changing it in {{navbox}} (and possibly other templates). — Edokter • Talk • 19:41, 26 March 2008 (UTC)
That's great to know, but not exactly what I was asking. I was wanting to know if code could be added which would allow the exact width to be specified by someone using the collapsible class, while leaving a default width of 6em. For instance, if I were to want to cut its width to 3.5em, or increase it to 16em in one particular usage for whatever reason (not that I know what that reason would be, I'm just throwing a couple of examples out there). —Dinoguy1000 18:01, 27 March 2008 (UTC)
Ah, I see! I'm afraid that's not possible, as the show/hide link is added dynamically by this very script, so there is no way to account for it in the templates. — Edokter • Talk • 18:05, 27 March 2008 (UTC)
I figured as much, though I did think about the possibility of allowing it via the class attribute. But that goes off into a whole other realm of sticky issues. —Dinoguy1000 19:08, 27 March 2008 (UTC)

Geonotice temporarily removed

I've temporarily removed the geonotice feature because Wikipedia:Wikipedia Takes Manhattan has been postponed a week to April 4, and the geonotice was advertising the wrong date. Wikipedia Takes Manhattan was the only geonotice active at this time, so there's no collateral damage. I'm waiting for Gmaxwell (or whoever else is technically able) to update the geonotice date ASAP, so that we can restore it. Thanks.--Pharos (talk) 05:07, 27 March 2008 (UTC)

OK, I've restored it.--Pharos (talk) 05:56, 27 March 2008 (UTC)
I would like to point out that due to browser caching, there is little chance that this actually had any effect for anyone. As a matter of fact for the people who DID actually download this "disabled" version, we might now end up with people who won't have this active for quite a while (not sure what the caching on this page is, but for Common.css its 30days ) --TheDJ (talk • contribs) 11:38, 27 March 2008 (UTC)