MediaWiki talk:Common.js/Archive 17

Archive 10

←

Archive 15

Archive 16

Archive 17

"Yahoo" or "Yahoo!"

Just wanted to point out for accuracy sake, search drop down name should be 'Yahoo!' with exclamation not just Yahoo. --IncidentFlux ^{[ TalkBack | Contributions ]} 17:22, 28 June 2009 (UTC)

I copied the above post from Wikipedia talk:Searching#Search drop down name should be 'Yahoo!' with exclamation not just Yahoo. I'm neutral. "Yahoo!" is more official but the exclamation might look like we make one of the options stand out. PrimeHunter (talk) 16:24, 4 July 2009 (UTC)

Well, since it's a brand name, how about adding 'search', e.g.: Yahoo! search, 'Bing search' with all of them to neutralize the perception. --IncidentFlux ^{[ TalkBack | Contributions ]} 17:18, 4 July 2009 (UTC)

Mobile site redirecting

Any chance someone will try discussing these changes first? They say there's a community around here that usually likes to, at the very minimum, be warned about changes to the global JavaScript. (And it probably doesn't help that we redirected all traffic to the mobile site only to have it start serving 502s. Pretty nasty thing to do.) --MZMcBride (talk) 03:51, 7 June 2009 (UTC)

There better be. It is incredibly aggravating to be redirected to a less-functional website when my phone has a browser that is designed to view the web as you would normally. If I type "en.wikipedia.org" I want "en.wikipedia.org" not a crippled website that I didn't ask for. ~ Ameliorate! 06:23, 12 June 2009 (UTC)

Simply click the "View this page on regular Wikipedia" link and you will never be bothered by a mobile redirect again. These changes were discussed at length on IRC with most of Wikipedia's technical community in attendance. The mobile site is not meant for power users, as both of you obviously are, but you make up an extremely small segment of the community. Don't get me wrong, its an extremely *important* and *vital* part of the community and I'm not downplaying that. But when 99% of the users coming to this site prefer a simplified interface and have requested it roundly, we need to make sure those users are supported. If you have any suggestions on how to work with both types of users, I'd love to hear about it. Also, if you could suggest a place where you'd like to be notified of any future changes, let me know where you'd like me to report in the future. --Hampton (talk) 15:45, 26 June 2009 (UTC)

Also, I'll point you to this Village Pump Thread ... and you start to see why we started a redirect. --Hampton (talk) 15:45, 26 June 2009 (UTC)

At the very least, dropping a notice on the talkpage here with links to relevant discussions (or noting that such discussions took place on IRC) would be nice, since some of us who watch this page do not, in fact, watch VPT or the IRC channels (shock! =O ). 「ダイノガイ千？！」^{? · Talk⇒Dinoguy1000} 11:00, 27 June 2009 (UTC)

The Mobile Redirect code cannot go into an import because we need it to load before all of the other assets on the page. If you do an import, the page renders on the mobile device and THEN redirects which is angering a lot of users. Until the sysadmins get a chance to implement the redirect outside of Javascript, Brion and I have agreed this is best. --Hampton (talk) 21:19, 30 July 2009 (UTC)

Thank you for leaving a note on the talk page. :-) --MZMcBride (talk) 22:23, 30 July 2009 (UTC)

I echo MZMcBride's thanks, I greatly appreciate you taking the time to leave an explanation here (I can't speak for anyone else who watches this page, but I'm sure they do, too). =) 「ダイノガイ千？！」^{? · Talk⇒Dinoguy1000} 22:29, 30 July 2009 (UTC)

More functional breakdown

Following the 2008 discussion Functional breakdown by size when edits.js etc. were created, I'm wondering if it's possible to move some other code into separate modules. Particularly, "IPv6 AAAA connectivity testing" code which is used about 1 out of 100 page views, and "Mobile browser helper link" which is used, I would estimate, by less than 1% of visitors. — AlexSm 15:46, 24 June 2009 (UTC)

Yeah, I don't see why not. I personally think Common.js should simply be a list of imports, that can be enabled or disabled as required, but that could just be me. For the IPv6, I presume you are suggesting that the contents of the main conditional simply be moved to another page and replaced by the import? If no one objects here in the near future, I'll go ahead and move that to (following the existing naming scheme, which I like) MediaWiki:Common.js/IPv6.js. I'd possibly suggest talking to the maintainers of the mobile redirect, as I know they are actively developing that based on MediaWiki changes and changes to the mobile site. Ale_Jrb>^talk 22:09, 24 June 2009 (UTC)

I agree about the IPv6 code, and the mobile device code should also be moved to a subpage. Moving all the scripts to subpages is probably not a good idea--some scripts are simply needed too often to justify splitting them off. —Remember the dot ^(talk) 05:37, 26 June 2009 (UTC)

I've moved the little-used mobile redirect code to MediaWiki:Common.js/mobile.js. Since actual redirection for mobile devices is currently disabled, now seemed like a particularly good time to make the switch. Question: does the IPv6 tester even work any more? The page it links to is totally blank. —Remember the dot ^(talk) 03:16, 30 June 2009 (UTC)

Subpaging makes duplicating the code on other projects more tedious, it makes watching changes more tedious, and it only works for recent versions of MediaWiki (1.14 or later, I believe). I'm not saying we shouldn't subpage, but there are certainly reasons not to.

I'll try to poke someone about the IPv6 thing. --MZMcBride (talk) 02:50, 6 July 2009 (UTC)

To me, the problem is that we use way too much JavaScript. The Special:Search code, the IPv6 test, and the main page fixes should be implemented in PHP and not in JavaScript at all. Also, JavaScript commonly used across many projects should be made part of MediaWiki's standard JavaScript features. While the Squid servers effectively prevent a PHP solution for the mobile devices code, if we eliminated all the other extraneous JavaScript then our site JavaScript as a whole wouldn't be so bad. —Remember the dot ^(talk) 02:04, 9 July 2009 (UTC)

I moved the IPv6 code to another page, as there seemed to be no big issues with doing so. Common.js now stands at around 15Kb. Ale_Jrb^talk 09:44, 9 July 2009 (UTC)

The IPv6 code was broken for Vector and other skins not compatible with Monobook. I have repaired this. Mark is currently looking as to why the statistics pages are not OK. Instant update, disk space on the server apparently ran out. I'll keep an eye out for when it gets fixed, and will try to leave a note here after it's repaired again. —TheDJ (talk • contribs) 13:34, 13 July 2009 (UTC)

http://ipv6and4.labs.wikimedia.org/stats.html appears to be working again. --MZMcBride (talk) 19:07, 15 July 2009 (UTC)

Help

Please see the thread at Wikipedia:Reference_desk/Computing#Accessing_Wikipedia_through_my_iPhone. Wikipedia is utterly unreachable through my phone and there is no option offered for accessing it. And I very much doubt I'm the only one. --Dweller (talk) 09:31, 8 July 2009 (UTC)

"Object does not support this method or property" on IE8

The line if( document.getElementsByClassName( 'shuffle' ) ){ is causing IE8 to whine that "Object does not support this property or method". Shouldn't it be something like if( getElementsByClassName( document, 'div', 'shuffle' ) ){? --Jack Phoenix _(Contact) 22:21, 12 July 2009 (UTC)

Someone apparently forgot what he wrote here ;) —Ruud 01:38, 13 July 2009 (UTC)

Yes, the fact that no edit to JavaScript is ever silent or unnoticeable... I haven't had a large fish slapped on my talk page yet, would someone like to oblige? :D Happy‑melon 12:58, 13 July 2009 (UTC)

I obliged! =D 「ダイノガイ千？！」^{? · Talk⇒Dinoguy1000} 21:37, 13 July 2009 (UTC)

This is quite enough. You started a thread on a talk page, didn't gain any type of consensus for the feature, and then added code to Common.js citing the discussion you started. What? Where in this chain of events did this seem like it was following any kind of guideline? This is simply unacceptable. --MZMcBride (talk) 19:01, 14 July 2009 (UTC)

... said the raven to the crow. And this horse is quite dead already anyway, thank you. Amalthea 19:38, 14 July 2009 (UTC)

Um, no. This isn't the first "incident" with regard to the global JavaScript pages and this particular user. This is a demonstrated, repeated problem. The "omg trout me" nonsense is inappropriate in light of the circumstances. As is suggesting that commenting on this on July 14 when the original thread was started July 12 is beating a dead horse. Thanks. --MZMcBride (talk) 19:42, 14 July 2009 (UTC)

No one is going to add this particular script back in. Melon himself acknowledged that the feature isn't wanted.
And concerning previous incidents, I haven't always had this page watchlisted, but at least MediaWiki:Common.js wasn't even edited by Happy Melon in the last six months. Could you enlighten me about details? Amalthea 19:58, 14 July 2009 (UTC)

It's a matter of excessive boldness, in my view, but I don't think dragging out prior bad acts is really helpful. Aitias left a note on Happy-melon's talk page. That should be sufficient (I hope). Happy-melon literally wrote the book on this particular problem (i.e., bold changes to MediaWiki messages), as Ruud pointed out. I hope not to see a repeat of this in the future. Our site is simply too big and too viewed to be making errors like this. Cheers. --MZMcBride (talk) 20:43, 14 July 2009 (UTC)

Which is pretty much what I said: Melon has been cautioned be several people and has accepted and acknowledged it. There was little need to rehash this, in particular when no evidence of a "demonstrated, repeated problem" is produced. Cheers, Amalthea 20:54, 14 July 2009 (UTC)

Things like this are what I'm talking about (and that was just looking at very recent contributions). There's an entire wiki devoted to testing (test.wikipedia.org) or there are dozens of test wikis available. There are other edits I could point out, but you seem to simultaneously want me to back away from this while also providing evidence to prove my point. I think they call this a "lose-lose" where I'm from. :-) --MZMcBride (talk) 21:02, 14 July 2009 (UTC)

I remembered that one. It's not on a JavaScript page affecting all users, which is where you previously saw a pattern, and after checking, in the half-year period I mentioned above Melon made exactly one other edit to a .js page in MediaWiki space. I don't know when the last incident might have been, but we're unbanning people in shorter periods so I think it's fair to say that yes, this was the first incident with regard to global JavaScript pages and this particular user.
And I don't really want anything. Your post, quite simply, appeared to me to have no purpose other than reviving an issue I felt was quite satisfyingly resolved, since I don't see a pattern of negligence in Melon's edits that needs addressing. And if there is, I think it's safe to say that the point has now sunken in with the reminders by numerous people on at least three pages, so that we hopefully can put this to rest. Cheers, Amalthea 21:49, 14 July 2009 (UTC)

Perhaps the warning that appears when you try to edit this page should be tweaked to encourage a little more though before making a bold edit and state the possible consequences of introducing errors on this page (e.g. popping up an error box for 75% of all visitors.) And maybe be it should be red and blinking as well :p —Ruud 22:48, 14 July 2009 (UTC)

How about

?? Happy‑melon 12:53, 17 July 2009 (UTC)

I like it; it's slightly amusing yet clearly serious. I'd put the whole first sentence in bold, personally, as that's the really important part. Ale_Jrb^talk 13:08, 17 July 2009 (UTC)

Same here. Give me a minute, and I'll tweak the wording, too. =) 「ダイノガイ千？！」^{? · Talk⇒Dinoguy1000} 18:52, 17 July 2009 (UTC)

border="1" in tables

Last year we hacked the formatting of wikitables to help them appear with borders when rendering in environments without CSS (see discussion). Now that is coming round to bite us: with the recent wikitech-l thread supporting a move to HTML 5 ([1] and subsequent), we now have a horde of markup on enwiki that is going to become invalid [2]; see the extensive discussion at T20829, which WONTFIXed the idea of applying this style more widely.

I don't think we should give ourselves the task of removing existing invalid attributes at this stage (things like cellspacing, cellpadding and even align are invalid HTML5); the shift from XHTML-1.0-transitional, which we use at the moment, is going to be very slow and steady, and these attributes will not break output, they will just cause validation errors. But it would be eminently sensible for us to stop continually making the problem worse, by updating our documentation to encourage the correct formatting, and by reverting the change to MediaWiki:Common.js/edit.js which means every table added using the edit toolbar is added broken. Thoughts? (also)Happy‑melon 09:19, 24 July 2009 (UTC)

• I agree, no point in leaving that in. —TheDJ (talk • contribs) 11:00, 24 July 2009 (UTC)
• Well I think we should start by warning users about using the already deprecated (HTML4) font tag in their signatures **cough**. — Dispenser 11:29, 24 July 2009 (UTC)

  Ouch :D To be fair, I have been planning to change it ever since I heard about HTML5 and started looking into it, but I hadn't got around to it. First sig change since 2006!! It also deprecates <tt>...</tt>, which I use all the time... :( (also)Happy‑melon 12:58, 24 July 2009 (UTC)

• Yikes, switching from XHTML will require reworking almost all Twinkle scripts. And not being able to use XPath any longer will suck as well. Hmpf, I guess I'll have a look at jQuery.
  But anyway, yes, removing border="1" in anticipation sounds like a good idea. I'd suggest adding a rule to remove border, cellpadding, cellspacing, etc. to the AWB general fixes before long, too.
  Amalthea 11:53, 24 July 2009 (UTC)

  From the wikitech-l discussion (see also mw:HTML 5) we'll keep trying to serve valid XHTML-1.0 for a fair while longer, until we're totally sick-and-tired of bending over backwards and shouting at screen-scraping bots/scripts to start using the API. Certainly there should be plenty of crossover time with jQuery.
  class="wikitable" border="1" can certainly be trivially removed by AWB. Cellpadding and cellspacing will be somewhat harder to deal with since they'll affect appearance if they're just blindly removed. (also)Happy‑melon 12:58, 24 July 2009 (UTC)

  edit conflict It's just Garrett wanting to be cruel to bot operators (and everyone not on the bleeding edge) and not realizing that not every is available via API. Brion has already pointed out that there will be XHTML version of HTML5. — Dispenser 13:11, 24 July 2009 (UTC)

  For manipulation of the page content (like Twinkle's rollback/revert links) and for several feature where the script input necessarily comes from the current page (batch deletion & protection) I'll always have to parse the rendered & skinned output the user currently sees, scream as you might.
  Amalthea 13:43, 24 July 2009 (UTC)

  It's not me screaming! I don't think Twinkle is the focus of his wrath: that's reserved for pywiki... (also)Happy‑melon 15:01, 24 July 2009 (UTC)

• Hold until somebody solves and implements a fix for the copy'n'paste issue, preferably so that install based > HTML 5 only users. — Dispenser 15:26, 24 July 2009 (UTC)

  There is no magic 'solution' to the copy-and-paste issue: the expectations of those reusers are fundamentally divergent from the prevailing policies in web design for the past ten years. Style is separate from content; reuses which do not follow that philosophy are not living in the modern world.

  Now, we can continue to support this deviation; we'd need to replace border="1" with style="border:1px solid;". I'm not fundamentally opposed to that. But I wouldn't be at all surprised to hear that in five years time HTML 6 or 7 deprecates the style element entirely - that's the direction we're going in. It's important to approach this from the perspective of legacy support: this is no different to IEfixes or the other style hacks we have - we are taking ABCD steps to accomodate user agents that render this material improperly. Happy‑melon 21:08, 24 July 2009 (UTC)

I don't understand why we need the border to be specified at all. There is lots of stuff that will look terrible if Common.css is not used - why focus on this one tiny thing? I think we should just remove it. --- RockMFR 20:57, 25 July 2009 (UTC)

I agree. This hack should never have been implemented. —Remember the dot ^(talk) 19:08, 26 July 2009 (UTC)

highlighting the edit tab

If you look at articles on the polish wikipedia such as say pl:Frank_McCourt you can see that they use javascript to highlight the tab to a greater extent than we do. Any objections to implementing this on en?©Geni 16:30, 25 July 2009 (UTC)

Yes. --- RockMFR 16:37, 25 July 2009 (UTC)

Any they are?©Geni 16:42, 25 July 2009 (UTC)

Even if this was visually desirable, CSS would be a much better way to implement it than JavaScript. —Remember the dot ^(talk) 17:54, 25 July 2009 (UTC)

That was my intial assumption but pl has done it via javescript.©Geni 18:32, 25 July 2009 (UTC)

pl.wiki has done it poorly, then. In any case, I dislike having the "edit" tab highlighted. EVula // talk // ☯ // 19:28, 26 July 2009 (UTC)

What is the advantage of highlighting the edit tab? There's an argument to highlight the discussion tab, if any. We'd have a better encyclopedia if there was more discussion. --Dweller (talk) 19:24, 10 August 2009 (UTC)

Removing disambig check in magic editintros

I think we can remove getElementById('disambig') from the editintros code now - I changed the id to disambigbox quite a while ago. --- RockMFR 22:23, 5 August 2009 (UTC)

Sorry

Sorry about that. The code was tested, but i missed a bracket in the copy paste. —TheDJ (talk • contribs) 20:05, 22 August 2009 (UTC)

Adding a delete tab for user subpages

I think adding toolbox link or a tab that says "request deletion" or "delete" for logged-in users who are viewing their own user subpages would be nice. It would just prepend {{db-user}} with a quick edit after a confirmation dialog. Any thoughts? --MZMcBride (talk) 07:04, 18 October 2009 (UTC)

As long as the confirmation dialog clearly explains what the link is, where it appears, and what it means, I'm all for it. 「ダイノガイ千？！」^{? · Talk⇒Dinoguy1000} 18:26, 19 October 2009 (UTC)

How to insert a ＜br＞ in the toolbar?

Like this:


140.112.7.59 (talk) 06:52, 21 October 2009 (UTC)

Anontips banner

I'd like to disable the anontips banner ("Wikipedia is sustained by people like you. Please donate today.", etc.) before the start of the next fundraiser. This year's fundraiser banners will be particularly large and noticeable; there's really no need to clutter the reader's screen with multiple donate messages. In addition, the non-donate messages are stale and the break will hopefully give us some time to write fresh content. Any objections? --MZMcBride (talk) 00:37, 27 October 2009 (UTC)

Forgot that we have MediaWiki:Monobook.css too. Probably good if change some of the more stagnant elements in the site. Looking at the code I came up with the following improvement to shave bytes by using wikilinking.

div.innerHTML = message[whichMessage].replace(/\[\[([^[\]{|}]+)\]\]/g, "[[$1|$1]]").replace(/\[\[([^[\]{|}]+)\|(.+?)\]\]('??\w*)/g, '<a href="'+wgArticlePath+'" title="$1">$2$3</a>');

It has the add benefit that the links work better on the secure server. Also, for accessibility we should be attaching this div to the end of the page so it isn't the first text read aloud by screen readers. — Dispenser 03:41, 27 October 2009 (UTC)

Now we just a javascript implementation of the parser and we'll be set! — RockMFR 23:20, 27 October 2009 (UTC)

When does the fundraiser start ? What is the HTML that is going to be used for this years centralnotice ? I was pondering about just changing insertBefore() of the addition to an appendChild(), but I think there were browsers that had issues with appendChild(). I agree with MZMcBride that changing that is important, but does anyone remember which browsers were having trouble with appendChild and wether we still support those ? —TheDJ (talk • contribs) 23:39, 27 October 2009 (UTC)

According to m:Fundraising_2009/Timeline Soft launch on Nov 3 and full launch Nov 7. — Dispenser 02:13, 28 October 2009 (UTC)

So we'll add "needs a code rewrite" to the list of reasons I've now removed the banner. Copied below for posterity and for improvements. --MZMcBride (talk) 19:26, 28 October 2009 (UTC)

Extended content

/** Anon tips and donation banner ************************** * * Description: This implements an anon tips / donation banner. It includes a workaround for * the Z-index bug found in Internet Explorer. It correctly places the anon notice * on the page, even under IE6. See this Google search for more information about the bug: * http://www.google.com/search?q=z-index+ie6+bug * Maintainers: [[User:Gmaxwell]], [[User:MZMcBride]] */ if(wgUserName == null) addOnloadHook((function (){ var message=new Array(); message[0]='Your <a href="http://wikimediafoundation.org/wiki/Donate/Now/en class="extiw" title="wikimedia:Fundraising"><b>continued donations</b></a> keep Wikipedia running!'; message[1]='<a href="http://wikimediafoundation.org/wiki/Donate/Now/en class="extiw" title="foundation:Fundraising"><b>Make a donation</b></a> to Wikipedia and give the gift of knowledge!'; message[2]='Wikipedia is sustained by people like you. Please <a href="http://wikimediafoundation.org/wiki/Donate/Now/en class="extiw" title="foundation:fundraising"><b>donate</b></a> today.'; message[3]='Help us improve Wikipedia by <a href="http://wikimediafoundation.org/wiki/Donate/Now/en class="extiw" title="foundation:Fundraising"><b>supporting it financially</b></a>.'; message[4]='You can <a href="http://wikimediafoundation.org/wiki/Donate/Now/en class="extiw" title="wikimedia:Fundraising"><b>support Wikipedia</b></a> by making a tax-deductible donation.' message[5]='Help us provide free content to the world by <a href="http://wikimediafoundation.org/wiki/Donate/Now/en class="extiw" title="foundation:Fundraising"><b>donating today</b></a>!'; message[6]='<a href="http://en.wikipedia.org/wiki/Wikipedia:Researching_with_Wikipedia" title="Wikipedia:Researching with Wikipedia">Learn more about using Wikipedia for research.</a>'; message[7]='<a href="http://en.wikipedia.org/wiki/Wikipedia:Ten_things_you_may_not_know_about_Wikipedia" title="Wikipedia:Ten things you may not know about Wikipedia">Ten things you may not know about Wikipedia.</a>'; message[8]='<a href="http://en.wikipedia.org/wiki/Wikipedia:Ten_things_you_may_not_know_about_images_on_Wikipedia" title="Wikipedia:Ten things you may not know about images on Wikipedia">Ten things you may not know about images on Wikipedia.</a>'; message[9]='<a href="http://en.wikipedia.org/wiki/Wikipedia:Citing_Wikipedia" title="Wikipedia:Citing Wikipedia">Learn more about citing Wikipedia.</a>'; message[10]='Have questions? <a href="http://en.wikipedia.org/wiki/Wikipedia:Questions" title="Wikipedia:Questions">Find out how to ask questions and get answers.</a>'; message[11]='<a href="http://en.wikipedia.org/wiki/Wikipedia:Basic_navigation" title="Wikipedia:Basic navigation">Find out more about navigating Wikipedia and finding information.</a>'; message[12]='<a href="http://en.wikipedia.org/wiki/Wikipedia:Contributing_to_Wikipedia" title="Wikipedia:Contributing to Wikipedia">Interested in contributing to Wikipedia?</a>'; var weightLimit = 6; var biasPercent = 0.815; var whichMessage = (Math.random() < biasPercent) ? weightLimit : message.length; whichMessage = Math.floor(Math.random() * whichMessage); var wrapper = document.getElementById("globalWrapper"); if (wrapper) { var div = document.createElement('div'); div.id = "anon-banner"; div.className = "noprint"; div.style.cssText = "position:absolute; z-index:40; left:155px; top:1px; clear:both; float:left; font-size:90%; font-style:italic; white-space:nowrap"; div.innerHTML = message[whichMessage]; wrapper.insertBefore(div, wrapper.firstChild); } }));

Simplify

Hello!

I think we could simplify this code from the function toggleNavigationBar

            if ( hasClass( NavChild, 'NavPic' ) ) {
                NavChild.style.display = 'none';
            }
            if ( hasClass( NavChild, 'NavContent') ) {
                NavChild.style.display = 'none';
            }

to

            if ( hasClass( NavChild, 'NavPic' ) || hasClass( NavChild, 'NavContent') ) {
                NavChild.style.display = 'none';
            }

and this one

            if (hasClass(NavChild, 'NavPic')) {
                NavChild.style.display = 'block';
            }
            if (hasClass(NavChild, 'NavContent')) {
                NavChild.style.display = 'block';
            }

to

            if (hasClass(NavChild, 'NavPic') || hasClass(NavChild, 'NavContent')) {
                NavChild.style.display = 'block';
            }

What do you think? Helder (talk) 18:47, 29 October 2009 (UTC)

No objections. Though realistically, it won't make much of a difference in both speed and size of the script. —TheDJ (talk • contribs) 19:49, 29 October 2009 (UTC)

Or maybe all this part

    // if shown now
    if (NavToggle.firstChild.data == NavigationBarHide) {
        for (var NavChild = NavFrame.firstChild; NavChild != null; NavChild = NavChild.nextSibling) {
            if ( hasClass( NavChild, 'NavPic' ) ) {
                NavChild.style.display = 'none';
            }
            if ( hasClass( NavChild, 'NavContent') ) {
                NavChild.style.display = 'none';
            }
        }
    NavToggle.firstChild.data = NavigationBarShow;
 
    // if hidden now
    } else if (NavToggle.firstChild.data == NavigationBarShow) {
        for (var NavChild = NavFrame.firstChild; NavChild != null; NavChild = NavChild.nextSibling) {
            if (hasClass(NavChild, 'NavPic')) {
                NavChild.style.display = 'block';
            }
            if (hasClass(NavChild, 'NavContent')) {
                NavChild.style.display = 'block';
            }
        }
        NavToggle.firstChild.data = NavigationBarHide;
    }

could be changed to

    for (var NavChild = NavFrame.firstChild; NavChild != null; NavChild = NavChild.nextSibling) {
        if (hasClass(NavChild, 'NavPic') || hasClass(NavChild, 'NavContent')) {
            NavChild.style.display = (NavToggle.firstChild.data == NavigationBarHide) ? 'none' : 'block'
        }
    }

It seems a lot simpler, isn't? ;-) Helder (talk) 18:20, 30 October 2009 (UTC)

Add the forgotten NavToggle.firstChild.data = ... and then your code is very similar to what I had for a year in ru:MediaWiki:Common.js (collapseDiv() function), so naturally I support this simplification. However, the en.wp style of JS programming seems to be "the more lines of code, the merrier". — AlexSm 19:31, 30 October 2009 (UTC)

Special:MySkin

As currently being discussed under Wikipedia:Village_pump_(technical)#Special:Myskin.js.2F.css_.3F I would like to add some short code to dynamically replace Special:MySkin.js links with Special:MyPage/skin.js links (with "skin" being the current skin of the user, same for .css). The code can be found on User:Cacycle/myskinify.js (install using importScript('User:Cacycle/myskinify.js');). This would allow linking to users skin.js and skin.css pages independent of the skin they are currently using. It will help with the confusion of the upcoming change of the default skin from monobook to vector. This is meant to be a quick and temporary fix until Special:MySkin gets hardcoded into MediaWiki. The short code works under all skins and with the current versions of Firefox, Chrome, Opera, and IE. The execution time should be negligible and I do not think it would interact with any existing script or gadget. Cacycle (talk) 03:08, 16 October 2009 (UTC)

How does the script handle junk titles (e.g. Special:MySkin or Special:MySkin.jsl), or does it just ignore these? 「ダイノガイ千？！」^{? · Talk⇒Dinoguy1000} 18:37, 16 October 2009 (UTC)

Correctly, from what I can tell. Try it: Special:MySkin.js sPeCiAl:mYsKiN.CsS Special:MySkin.FOO. Just execute javascript:void(importScript('User:Cacycle/myskinify.js')) in your browser's address bar while on this page to see what it does.
There's a rather hypothetical issue since it doesn't check the target domain, so if I post an external link like http://example.com?q=special:myskin.js it will do its magic, too, without even showing it. That's rather harmless, worst I can do with that is build a link to a server I have access to to collect statistics about what skin a user has. Amalthea 19:11, 16 October 2009 (UTC)

I think it would be much better to catch these links at the destination page, i.e. Special:MySkin.js and Special:MySkin.css. This way it would take almost zero processing time on all other pages, only 2 lines in Common.js and the rest will be in a separate script:

if (wgCanonicalNamespace=='Special' && /myskin\.(js|css)/i.test(wgTitle)) 
  importScript('MediaWiki:Common.js/myskin.js')

P.S. Could you please elaborate on the "upcoming change to vector"? — AlexSm 19:14, 16 October 2009 (UTC)

Drawback is that they stay redlinked. And the upcoming change is I guess that it will be made the default skin at some point. Amalthea 19:21, 16 October 2009 (UTC)

Alex: That is a good idea. But if you run the script on the Special:MySkin.js page, then the links to that page will be red and you have to execute a redirect. From my understanding, vector will soon become the default skin, thereby replacing monobook. It is already in public beta testing (see the "Try Beta" link at the top of the page. Cacycle (talk) 19:54, 16 October 2009 (UTC)

I don't see "always red" as a huge drawback, considering that "always blue" approach seems to be equally wrong. Anyway, we could use special:mypage/myskin.js blue links and import the redirecting script at /myskin.js user pages. — AlexSm 20:25, 16 October 2009 (UTC)

Vector skin is only a part of beta interface, and it's possible it will stay optional unlike beta toolbar. — AlexSm 20:25, 16 October 2009 (UTC)

Another question: is there any indication that Special:MySkin.js will ever get hardcoded in MediaWiki, and if it will, what's going to happen to the proposed "quick and temporary fix" and all existing Special:MySkin.js links if devs implement some other special page name? — AlexSm 20:25, 16 October 2009 (UTC)

Alex's Special:MyPage/MySkin.js / Special:MyPage/MySkin.css is a good sugestion: it generates blue links, it would need much less unnecessary code execution, and it would be the only reasonable forward-compatible solution that I can think of. I will create a test implementation later tonight. And if developers decide to implement Special:MySkin.js and Special:MySkin.css then we could update the links I guess :-) Cacycle (talk) 00:24, 17 October 2009 (UTC)

Check this: importScript('User:Cacycle/myskinforward.js'); Cacycle (talk) 03:58, 17 October 2009 (UTC)

Any opinions against adding these few lines of code to Common.js? Cacycle (talk) 12:31, 20 October 2009 (UTC)

I had a read through, checked the code. It all looks fine to me, and I would have no issue with the code being added. Ale_Jrb^talk 17:34, 20 October 2009 (UTC)

I will go ahead and add this code if nobody objects. I will also go ahead and document the new functionality on the relevant pages. Cacycle (talk) 21:58, 29 October 2009 (UTC)

Added. Cacycle (talk) 16:30, 31 October 2009 (UTC)

There is a skin called MySkin for Stylish skinning, the new code conflicts with this reserved name. Maybe we should leave it as /skin.(js|css), and remove the case insensitivity. — Dispenser 17:10, 31 October 2009 (UTC)

Oops... I will change the code from myskin to skin and keep the case insensitivity. Cacycle (talk) 23:02, 31 October 2009 (UTC)

Why is this being done with a JavaScript-only override at all? It sounds like the sort of sensible redirect that should be added to the core software. Actually, what the software needs is a MyPage/Common.js and a MyPage/Common.css (or Custom.js/css?). It's a little bonkers that if you change skin, you have to copy all old scripts and css, since some of it works (or degrades gracefully) across all skins, and it ought to be possible for people to put it in a common place. • Anakin ^(talk) 19:17, 11 November 2009 (UTC)

"It will help with the confusion of the upcoming change of the default skin from monobook to vector. This is meant to be a quick and temporary fix until Special:MySkin gets hardcoded into MediaWiki." —TheDJ (talk • contribs) 19:30, 11 November 2009 (UTC)

Ah, sorry, I'm an idiot; I tried to read too quickly. Wait, what?! Vector's horrid! Was there a discussion on switching? • Anakin ^(talk) 19:41, 11 November 2009 (UTC)

One day it will be the default interface for anon and new users. But if you don't change, then no one will force you. —TheDJ (talk • contribs) 19:48, 11 November 2009 (UTC)

Redirect Series60 devices to mobile site

{{editprotected}} Please add automatic redirect support for Series60 browser devices accessing wikipedia. This includes a large portion of Nokia Nseries devices such as N95 and above. N95 User agent string looks like this:

Mozilla/5.0 (SymbianOS/9.2; U; Series60/3.1 NokiaN95/20.0.015; Profile/MIDP-2.0 Configuration/CLDC-1.1 ) AppleWebKit/413 (KHTML, like Gecko) Safari/413

More documentation on http://wiki.forum.nokia.com/index.php/User-Agent_headers_for_Nokia_devices

I suggest changing line

if (/(Android|iPhone|iPod|webOS|NetFront|Opera Mini|SEMC-Browser|PlayStation Portable|Nintendo Wii)/.test(navigator.userAgent)) {

to

if (/(Android|iPhone|iPod|webOS|NetFront|Opera Mini|SEMC-Browser|PlayStation Portable|Nintendo Wii|SymbianOS)/.test(navigator.userAgent)) {

—Preceding unsigned comment added by Grille Chompa (talk • contribs)

Please allow time for discussion before placing editprotected requests. Thanks. — Martin (MSGJ · talk) 12:22, 8 November 2009 (UTC)

Support was explicitly removed. We had to do this because the S60 series has too many differences between the devices, and we don't have enough devices to test with. You can use the mobile version by manually going to http://en.m.wikipedia.org. I'm pondering adding a link to the interface to make the mobile page more reachable for unsupported devices. —TheDJ (talk • contribs) 14:11, 25 November 2009 (UTC)

Line break button should insert <br>

The line break button on the edit toolbar (MediaWiki:Common.js/edit.js) currently inserts <br />, for XHTML compatibilty. I believe that good old <br> is a better choice for several reasons:

1. We use wikitext, not (X)HTML. The fact that wikitext borrows some HTML tags doesn't change this.
2. One of the points of wikitext is to be simpler than (X)HTML and its cruft.
3. The Wikipedia Usability Initiative is already trying to make Wikipedia easier to edit. It would be helpful to drop unnecessary punctuation like this that will make no sense to most people. "<br />" is more complicated syntax yet it achieves nothing.
4. The MediaWiki parser, in its desire to output XHTML transitional, is more than capable of sorting out the tags. It totally reparses and regenerates them from scratch. " /" is unnecessary extra parsing work, as it's dropped during parsing and MediaWiki puts in a new one. (It's the same as leaving out </td> and </tr> in tables as if in HTML -- MediaWiki will still put them in the output. It's smart like that.)
5. Wikitext should be stable. We shouldn't be trying to accommodate in our articles' wikitext for the latest doctype fad. What if the preferred doctype or most common format for viewing Wikipedia changes? E.g., if you export as PDF it generates totally different output syntax, and Mobile.wikipedia.org uses plain HTML 4.
6. <br> looks nicer (it's punctuated symmetrically).

• Anakin ^(talk) 01:57, 10 November 2009 (UTC)

I agree with Anakin, the line break button in the edit toolbar should insert <br>, not <br />. The discussion about which one to use pops up every now and then in different places. So I have a standard text that I use to respond to that. My apologies for the perhaps slightly hard tone in it, and that my text repeats some of Anakin's arguments above:

Well, <br> is the correct "HTML wikimarkup". But MediaWiki was updated to also understand <br /> some years ago so that it would be easier to copy and paste text from other free sources without having to modify each br tag in those texts.

Remember that wikimarkup should be as easy as possible so that normal people (non-webmasters) can edit Wikipedia. Wikipedia then parses and converts the wikimarkup to whatever is the current standard for web page rendering. And today (2009) that happens to be XHTML 1.0 Transitional. Tomorrow it might be something totally different, like PDF. Oh wait, we already do render to PDF for those that want that!

And note that the very similar <br \>, <br\>, </br>, </ br>, <\br> and <\ br> all are faulty variants. And the variant <br/> (without space) is not a recommended variant of the <br /> tag, according to the World Wide Web Consortium (W3C), since it breaks older web browsers.

So I suggest we stick to the simple wikimarkup <br> tag and not change all our 18 million pages every time the web standards change.

By the way, the "HTML tidy" function in MediaWiki's page rendering does fix some of the other faulty ways to write the br tag when it renders a page, that's why you get away with some variants like <br \>.

In April 2009 Brion Vibber, lead developer of MediaWiki, said:

In my experience XHTML 1.1 and later are a dead end; HTML 5 is where all the action is in browser support development.

There’s also no particular advantage for the “strict” DTD variants; good clean code can be written with or without it, but the “strict” deprecations are often arbitrary and require jumping through more hoops to replicate simple features.

So in a not too distant future the MediaWiki page renderer might be converting <br /> in wiki code to <br> in the rendered pages. Again, wikimarkup is not the same thing as rendered page code.

--David Göthberg (talk) 05:18, 10 November 2009 (UTC)

A few comments:

1. I would argue that "best practice" is to use <br />, not <br>;
2. Because users are clicking a convenience button to insert the code (instead of writing it themselves), a lot of the arguments about it being easier for the user don't really hold much weight;
3. Even the symmetry argument seems a bit odd to me—you sort of want the code to stand out like <br />, not blend in with text like <br> does;
4. By encouraging <br>, you also encourage some confusion about self-closing tags versus non-self-closing tags. Plenty of pages contain </br> for this reason;
5. Lastly, the <br /> code draws a parallel to the <references /> and <ref name="foo" /> code.

I don't really have strong views one way or the other. If forced to pick, I would suggest leaving the code as it is, though I do think it's important to consider both sides the debate. Just some food for thought. --MZMcBride (talk) 09:04, 10 November 2009 (UTC)

MediaWiki renders the HTML output, which is then run through HTML Tidy to do some cleanup. We should not rely on HTML Tidy to do this, as content is reused on other wikis where HTML Tidy is not implemented. We are slowly moving towards HTML 5, where <br> is correct.[3] but, we currently set the DOCTYPE to XHTML 1.0 Transitional, where <br /> is correct. ---— Gadget850 (Ed) ^talk 12:17, 10 November 2009 (UTC)

Agreed, though I think it is a non-issue. We also need to remember that there are (or at least used to be) several "cleanup" tools that automatically turn <br> into <br />. Also all browsers will understand both forms, so there is no technical reason for the choice, it is only a choice of esthetics. And I find the statement "we should not try to accommodate in our articles' wikitext for the latest doctype fad" an oversimplification of what xhtml was. It was a failure, not a stupid idea. Also, by striving towards html5, we are basically again following the same "fad". And as much as mobile.wikipedia.org might be HTML 4, our WAP2 portal is simple XHTML. We convert and translate all over the place, it does not matter, there is no hurry. I don't see the reason of changing this right now. —TheDJ (talk • contribs) 13:43, 10 November 2009 (UTC)

We are here talking about the wikicode part (that resembles HTML), not about the HTML code that the parser or HTMLTidy generate from it. We should change the button text and add some recommendations to the Wikipedia:Manual of Style. Cacycle (talk) 14:20, 10 November 2009 (UTC)

Gadget850 and TheDJ: You seem to forget that the markup we use here at Wikipedia is not HTML, nor XHTML, instead it is wikimarkup. And wikimarkup should be simple and easy to use, since this is the encyclopedia that anyone can edit. Using <br /> is harder for most users, since they tend to mix up what slash to use, and where to put it. So the toolbar button should use the easier markup, since people learn markup from such tools.

If you are so worried about reuse of our wikitext, then do you mean we should stop using wikimarkup altogether? Which one of the below markups do you prefer for bold text?

• '''Bold'''
• <b>Bold</b>
• <span style="font-weight:bold;">Bold</span>

As far as I know '''bold''' is the one we recommend for bold text, while the span markup is the one that W3C recommends. '''Bold''' is also the markup currently used by the bold text button in the edit toolbar. '''Bold''' doesn't work in other systems, still we use it. Wikimarkup is what we edit and input here at Wikipedia. The editors don't have to worry about what the system then renders with that.

--David Göthberg (talk) 17:03, 10 November 2009 (UTC)

I understand perfectly. That's why I said it doesn't matter from a technical point of view (Countering earlier comments). I said that I don't see a need to start changing yet again at this moment in time. I said that there are tools (format script and wikEd?) out there, that will do the opposite at this moment in time. —TheDJ (talk • contribs) 21:03, 10 November 2009 (UTC)

<br> is not wikitext. Its just one of the HTML tags that the parser doesn't escape, and happens to be converted to the proper form by Tidy. Given that most browsers should understand both forms, it really doesn't matter, but arguing that its better because its "wikitext" is just wrong. Mr.Z-man 17:20, 10 November 2009 (UTC)

Mr.Z-man: If you are responding to my messages above: This is what I meant: From an editors point of view it doesn't matter how MediaWiki works under the hood, and they shouldn't have to worry about that. Most of our editors here are not web masters or computer geeks, instead they come from all walks of life. What matters for our editors is that the markup should be easy to learn and easy to use. And <br> is easier to learn and use than <br />.

--David Göthberg (talk) 18:11, 10 November 2009 (UTC)

The break tag is HTML; it is not wikimarkup. MediaWiki allows certain HTML markup to pass-through without change. As long as pages render as XHTML 1.0 Transitional, then <br /> is the correct tag. If and when we switch to HTML 5, then we use <br> and make other changes to conform. ---— Gadget850 (Ed) ^talk 18:31, 10 November 2009 (UTC)

Regardless of how Mediawiki/Tidy handles the break; <br> is considered valid wiki-markup for the purpose of editing. The documentation reflects this. So I do favor the use of <br>. — Edokter • Talk • 02:17, 11 November 2009 (UTC)

My personal opinion is that <br> is the right tag to encourage users to use, as it is free of unnecessary frills. Right now the parser automagically converts <br> to <br /> to satisfy XHTML 1. In the near future we will be moving to HTML 5, and then I assume the parser will automagically convert <br /> to <br>, but the question of what code is output for the benefit of browsers and standards is largely irrelevant. The question is what code is easier for editors to understand and deal with. In my mind, <br> easily wins that contest, and even though people clicking on a button don't have to write it out, I still think the button should generate code in a form that is as easy as possible for editors to understand. Dragons flight (talk) 18:46, 10 November 2009 (UTC)

Concur. All allowed markup is to make life easier for editors; the semantics of how it's passed through from wikitext to final output is not relevant. <br> is cleaner and easier to understand than <br />, so we should use that; simple. What "a vertical separator" happens to look like in whatever output format MW happens to be using is not relevant to the question of "what should a vertical separator look like in wikimarkup?" Happy‑melon 19:13, 10 November 2009 (UTC)

I agree. When editing what we see is what is in the edit box, and the code whe use there is suposed to be easy to understand. Personally I think <br> is the easier. Helder (talk) 22:45, 10 November 2009 (UTC)

TheDJ: The usage of <br /> confuses the editors. They often add for instance </br> or <br\>, which is invalid markup. Like in the wikitable here: [4]. Using <br> doesn't cause such confusion. So we do need to change to the less confusing markup.

And I am aware that there are editing tools out there that tries to enforce <br />. But that is not an argument against using better markup, instead it means those tools should be fixed.

--David Göthberg (talk) 23:49, 10 November 2009 (UTC)

So— we are getting HTML 5 and Liquid Threads next week? If we want to change the W3C specification, should we alert them? Encouraging incorrect use of a tag simply on the grounds of aesthetics is just... ---— Gadget850 (Ed) ^talk 00:51, 11 November 2009 (UTC)

Actually HTML 5 is probably going to be turned on in the next major Mediawiki release. Regardless though, it's not an "incorrect use" because <br> is never shown to browsers, it's just another bit of wiki markup from Mediawiki's point of view, and therefore we should choose whatever is convenient for editors to use and understand. W3C is irrelevant to this discussion. Dragons flight (talk) 02:33, 11 November 2009 (UTC)

(unindent) At the moment, aren't all (encouraged) tags either explicitly closed or self-closing in wikimarkup (which, for the purpose of this comment, will include HTML and pseudo-HTML)? I'm thinking of <ref></ref>, <ref name="foo" />, <nowiki></nowiki>, <nowiki/>, etc. My concern is that <br> is going to be the single exception—something surely to cause more confusion. (And, really, nobody should be using <br />/<br> in normal article text anyway.) --MZMcBride (talk) 03:59, 11 November 2009 (UTC)

It always has been the exception that <br> has no closing equivalent in html. And yes, forcing a linebreak is sometimes necessary. — Edokter • Talk • 12:31, 11 November 2009 (UTC)

A few replies to comments since I started this-- MZMcBride, though I see the desire for consistency with other tags, it already confuses people, regardless of whether it's the exception or not, and people screwing up ref tags is already common. <references /> being different is less important as it's used less -- added usually only once in an article's life and often via {{reflist}}. <nowiki/> as far as I know is only a trick to avoid trimming whitespace in template arguments, hardly something a newbie would need. (Is it used anywhere else?) I think consistency with other tags is much less likely to confuse people than what the extra "/" does at all. E.g., people don't try to close template syntax or wikilinks, even when they try to use angle brackets for them.

To Gadget850-- correct me if I'm mistaken, but I don't think it's Tidy that does this. I think it's this. I have Tidy turned off on my own wiki and it still converts variations of this tag to <br /> to match with the XHTML doctype. Since it does this, the output will always work in both XHTML and HTML.

To all-- I've gone through the full spectrum of advocating <BR>, <br>, <br/>, <br />, <br>, etc., so I don't feel that strongly about this. I'm not really in favour of a MOS rule advocating one variant or the other. I just think that <br> is simpler to understand. One place it's used a lot is for separating lists of names in infobox parameters, where there's usually already a lot of punctuation. • Anakin ^(talk) 19:13, 11 November 2009 (UTC)

Editnotice

I have added an editnotice to this page. The text for it is located in Template:JSfile, similar to the editnotice we have in place for CSS which is Template:skinfile. —TheDJ (talk • contribs) 14:14, 11 November 2009 (UTC)

MediaWiki:Common.js - Redirects from /User:UserName/myskin.js or .css to the user's actual skin page

That breaks IE7 for anon because wgUserName is null. Der Umherirrende 16:34, 11 November 2009 (UTC)

Yikes, will fix immediately —TheDJ (talk • contribs) 16:36, 11 November 2009 (UTC)

Error avoided, but a more elegant approach might be needed for anon users. —TheDJ (talk • contribs) 16:44, 11 November 2009 (UTC)

SVG files: links to rendered PNG images

Many users are not familiar with using SVG images available on Wikipedia/Commons in office applications, etc. This is particularly true, if the base size is small (example). Therefore, I suggest adding links to rendered PNG images in different sizes to the image page. This has already been implemented on de-WP and on Commons (see talk page). --Leyo 18:14, 12 November 2009 (UTC)

// SVG images: adds links to rendered PNG images in different resolutions
addOnloadHook(function() {
      if (wgAction == "view" && wgNamespaceNumber == 6 && wgTitle.substring(wgTitle.lastIndexOf(".")).toLowerCase() == ".svg") { 
      var file = document.getElementById("file");
      if (!file) return;  // might happen if MediaWiki can't render the SVG
      var div = document.createElement("div");
      div.appendChild(document.createTextNode("SVG rendered as PNG images in different resolutions:"));
      div.appendChild(document.createElement("br"));
      var a200 = document.createElement("a");
      a200.setAttribute("href", "http://commons.wikimedia.org/w/thumb.php?f=" + encodeURIComponent(wgTitle) + "&width=200px");
      a200.appendChild(document.createTextNode("200px"));
      var a500 = document.createElement("a");
      a500.setAttribute("href", "http://commons.wikimedia.org/w/thumb.php?f=" + encodeURIComponent(wgTitle) + "&width=500px");
      a500.appendChild(document.createTextNode("500px"));
      var a1000 = document.createElement("a");
      a1000.setAttribute("href", "http://commons.wikimedia.org/w/thumb.php?f=" + encodeURIComponent(wgTitle) + "&width=1000px");
      a1000.appendChild(document.createTextNode("1000px"));
      var a2000 = document.createElement("a");
      a2000.setAttribute("href", "http://commons.wikimedia.org/w/thumb.php?f=" + encodeURIComponent(wgTitle) + "&width=2000px");
      a2000.appendChild(document.createTextNode("2000px"));
      div.appendChild(a200);
      div.appendChild(document.createTextNode(", "));
      div.appendChild(a500);
      div.appendChild(document.createTextNode(", "));
      div.appendChild(a1000);
      div.appendChild(document.createTextNode(", "));
      div.appendChild(a2000);
      div.appendChild(document.createTextNode("."));
      file.parentNode.insertBefore(div, document.getElementById("file").nextSibling.nextSibling);
   }
});

This is the code in question. I think this would be a nice addition. I'm wondering if we should have a /file.js page for this however. What do you guys think ? Also, the usage of "nextSibling" should probably be avoided. —TheDJ (talk • contribs) 18:39, 24 November 2009 (UTC)

Yes, this would be a very useful addition. I tested the code above, it worked fine in my Firefox 2. As usual TheDJ's code run as smooth as butter. And yes, this should be added to a new /file.js page.

But I would like some tweaks:

1: I would like if its text said "This image rendered as PNG in some resolutions:" instead of "SVG rendered as PNG images in different resolutions:".

2: No need for a line break between the text and the image links. It looks better on one line. Even as one line it fits nicely on my 800x600 screen resolution.

2: I would like this to be placed below the line that says "(SVG file, nominally ...", instead of above it.

3: I like the sizes you choose, but the images should also be limited in height, since some images can be very high and narrow. This is to prevent humongous images from being created and loaded, which can be nasty if you have a slow computer or slow connection. I tested to add that to the code I ran, and it worked fine. (But only add the height limitation to the links, not the visible link texts, it looks ugly in text.)

But no matter the details, I think this should be deployed right away. We can discuss and modify the details later on.

--David Göthberg (talk) 01:11, 25 November 2009 (UTC)

Code prepared in MediaWiki:Common.js/file.js. To be loaded from Common.js with:

if( wgNamespaceNumber == 6 )
  importScript('MediaWiki:Common.js/file.js');

Most suggestions by David incorporated. I was wondering. Isn't "resolutions" a misnomer ? Perhaps we should just say "in different sizes" —TheDJ (talk • contribs) 14:07, 25 November 2009 (UTC)

I tested the new code in my Firefox 2, Opera 10.10 and my ridiculously old IE 5.5, it works fine in all of them. And it looks very nice. And I agree, "resolutions" is a misnomer. "Sizes" is more correct, shorter, and a more common word so the average user understands it better.

So I guess there is only one more thing to do: Deploy it? :))

--David Göthberg (talk) 16:35, 25 November 2009 (UTC)

 Done Deployed —TheDJ (talk • contribs) 17:50, 25 November 2009 (UTC)

Hmm, JavaScript can do loops, if you get what I mean... — AlexSm 20:43, 25 November 2009 (UTC)

// SVG images: adds links to rendered PNG images in different resolutions
function SVGThumbs() {
	var file = document.getElementById("file"); // might happen if MediaWiki can't render the SVG
	if (wgIsArticle && file && wgTitle.substring(wgTitle.lastIndexOf(".")).toLowerCase() == ".svg") { 
		function altSizeLink(size, title) {
			var a = document.createElement("A");
			a.setAttribute("href", wgServer + wgScriptPath + "/thumb.php?f=" + encodeURIComponent(wgTitle) + "&width=" + size + "&height=" + size);
			a.appendChild(document.createTextNode(title);
			return a
		};
		var container = document.createElement("P");
		with(container) {
			className = "SVGThumbs";
			appendChild(document.createTextNode("PNG renderings in other sizes"+": "));
			appendChild(altSizeLink('200px', "200px"));
			appendChild(document.createTextNode(", "));
			appendChild(altSizeLink('500px', "200px"));
			appendChild(document.createTextNode(", "));
			appendChild(altSizeLink('1024px', "1024px"));
			appendChild(document.createTextNode(", "));
			// Should we have a 1920x1080 (HD) option?
			appendChild(altSizeLink('2000px', "2000px"));
			appendChild(document.createTextNode("."));
		}
		var info = getElementsByClassName( file.parentNode, 'div', 'fullMedia' )[0];
		if( info ) info.appendChild(container);
	}
};
addOnloadHook( SVGThumbs );

Code untested. I think you use wgIsArticle instead of wgAction == "view" since things like purge renders a fully viewed page. You should be using wgServer + wgScriptPath, not all SVGs are at commons. We probably should be picking common screen resolutions like 1024x768, 1280x960, 1920x1080, 2048x1536. — Dispenser 21:06, 25 November 2009 (UTC)

I fixed the paths immediately, I think that was kinda important. —TheDJ (talk • contribs) 21:14, 25 November 2009 (UTC)

The list of appends is messy. Put them in an array and iterate? Ale_Jrb^talk 21:17, 25 November 2009 (UTC)

By that I mean the size, in case it isn't obvious. :) Ale_Jrb^talk 21:21, 25 November 2009 (UTC)

I doubt it will matter much in terms of efficiency, readability or speed. Now using a svgAltSize() function to at least keep the link generation a bit cleaner. —TheDJ (talk • contribs) 21:40, 25 November 2009 (UTC)

No, it doesn't matter much. Significantly better practise though. Meh. :) Ale_Jrb^talk 21:43, 25 November 2009 (UTC)

@Dispenser, the problem with "screen sizes" is of course that the width x height defined here, are the limits, not the dimensions of the ouput. Although I agree that other sizes might be more useful than the current ones. I tried to fix the path issue, just not really sure about a good identification method for commons atm (wgServer doesn't work, is always en.wp) —TheDJ (talk • contribs) 21:52, 25 November 2009 (UTC)

I prefer the current sizes: 200px, 500px, 1000px, 2000px. They are simple and clear. And as TheDJ pointed out, most images anyway don't have the proper height to width ratio to fit as desktop backgrounds (since I guess that is what Dispenser wants those sizes for).

TheDJ: I added id="mw-sharedupload" to MediaWiki:Sharedupload-desc-here to give you a clean and efficient way to detect the presence of that message. (MediaWiki:Sharedupload redirects there, so we can use that short id.)

--David Göthberg (talk) 04:20, 26 November 2009 (UTC)

Using such local id eliminates all users with non-en language in preferences. — AlexSm 04:30, 26 November 2009 (UTC)

I'm now checking for the sharedUploadNotice class, which is used by the div around the Shareduploadnotice. (Why isn't that an id????). I also figured out, that you cannot use thumb.php from the secure server, so using wgServer is out the window. —TheDJ (talk • contribs) 15:23, 26 November 2009 (UTC)

Yeah, on the secure server thumb.php complains "Error generating thumbnail" if it's a new file version, but once it's been generated before (e.g., on the second request), it works fine: https://secure.wikimedia.org/wikipedia/commons/w/thumb.php?f=Hawaii_turtle_2.JPG&width=1280. Could it just be a server config problem? (wouldn't be surprised -- a lot of Wikimedia server stuff seems to almost discriminate against the poor old secure server :-( ) • Anakin 18:10, 26 November 2009 (UTC)

OK, I asked Tim Starling:

• "thumb.php is broken and should really be a 403 if you access it from outside the server cluster"
• " if you use thumb.php, it's forwarded to the general cluster, not the image scaling cluster"
• "so all the fonts will be broken and it'll be cached forever like that"

I'm blanking file.js until I have rewritten it to a better version. —TheDJ (talk • contribs) 23:50, 26 November 2009 (UTC)

3rd version

OK, my 3rd version of the code. Now just patches the URL of the original thumb (since for SVG we always have png thumbs). Also, per popular request, a loop. This code is not yet live. —TheDJ (talk • contribs) 00:29, 27 November 2009 (UTC)

// SVG images: adds links to rendered PNG images in different resolutions
function SVGThumbs() {
	var file = document.getElementById("file"); // might fail if MediaWiki can't render the SVG
	if (file && wgIsArticle && wgTitle.substring(wgTitle.lastIndexOf(".")).toLowerCase() == ".svg") {
		var thumbu = file.getElementsByTagName('IMG')[0].src;
		var thumbs = file.getElementsByTagName('IMG')[0].width;
		if(!thumbu || !thumbs) return;

		function svgAltSize( w, title) {
			var path = thumbu.replace( "/"+thumbs+"px-", "/"+ w +"px-" );
			var a = document.createElement("A");
			a.setAttribute("href", path);
			a.appendChild(document.createTextNode(title));
			return a;
		}

		var p = document.createElement("p");
		p.className = "SVGThumbs";
		p.appendChild(document.createTextNode("This image rendered as PNG in other sizes"+": "));
		var l = new Array( 200, 500, 1000, 2000 )
                for( var i = 0; i < l.length; i++ ) {
			p.appendChild(svgAltSize( l[i], l[i] + "px"));
			if( i < l.length-1 ) p.appendChild(document.createTextNode(", "));
                }
		p.appendChild(document.createTextNode("."));
		var info = getElementsByClassName( file.parentNode, 'div', 'fullMedia' )[0];
		if( info ) info.appendChild(p);
	}
};
addOnloadHook( SVGThumbs )

TheDJ: Your above code looks good. It works in all three of my browsers: Firefox 2, Opera 10.10 and IE 5.5. And it also works when on the secure server. (Although the images are loaded insecure, but it seems all images on Wikipedia is loaded insecure so we can't do anything about that, which is evil...) I have read through the code and it seems like a good solution, since it uses the same URLs that normal image thumbnails use so it isn't abusing the servers.

I see that we could fairly easily add a little logic that checks the height to width ratio of the image, and then adjusts the width based on that, so we stay within the 200x200 size and so on. But there's no hurry in adding that, we can add that after this code has been live-tested for some days.

--David Göthberg (talk) 02:59, 27 November 2009 (UTC)

That code works, but might I suggest this alteration:

		var thumbu = file.getElementsByTagName('img')[0].src;
		if (!thumbu) return;
 		
		function svgAltSize(w, title) {
			var path = thumbu.replace(/\/\d+(px-[^\/]+$)/, "/" + w + "$1");

Otherwise it relies on the img's specified width on the page matching the width in the URL. It probably will, but there might be other strange influences at work that browsers get wrong: zooming, not having fully loaded the image yet (race condition?), etc. The other part of that regexp is to prevent matching on the wrong part of the URL if the file name includes something that looks like the size. E.g., http://upload.wikimedia.org/wikipedia/en/thumb/3/35/200px-stupid-file-name.svg/200px-200px-stupid-file-name.svg.png. Also the wgTitle logic could be shortened to the more elegant wgTitle.match(/\.svg$/i) if you wish. • Anakin 03:13, 27 November 2009 (UTC)

Deployed with suggestions. —TheDJ (talk • contribs) 23:13, 27 November 2009 (UTC)

And as usual, the new version works in all three of my browsers.

--David Göthberg (talk) 03:20, 28 November 2009 (UTC)

It is also deployed on Commons now. —TheDJ (talk • contribs) 13:26, 28 November 2009 (UTC)

What do you think about this change? Should it be implemented here, too? --Leyo 07:49, 3 December 2009 (UTC)

Smaller thumbnails for all large images

For years my private wiki has included similar links on the image description page (as a Mediawiki patch). However, the difference is that I included links for small thumb version on all large images. This is especially useful if the image is very large (e.g. 4+ megapixels) as it allows one the option to look at an intermediate sample image that preserves more features without being so large it is difficult to download and use. In my case, I had a standard sequence of thumb sizes and capped the possible links at the actual dimensions of the image. Should something similar be done here too? Dragons flight (talk) 21:20, 25 November 2009 (UTC)

What sizes are you suggesting? We currently have 200px, 500px, 1000px and 2000px. The smaller one of those is not a problem to download even on a slow modem connection.

And by "capped the possible links at the actual dimensions of the image" I assume you mean to not show links for PNGs larger than the nominal size of the SVG. But SVG images are fully scalable, so we should show also the larger sizes for them.

But perhaps you mean for other non-SVG images? But that is not needed, since if you want a small thumbnail just look in the file history below the image, right click the image there and choose "Save image as...". And if you want a larger version, then right click the main image on the page and choose "Save image as...". That gives you the size previewed on the page, not the full image linked to. And that one you already have in your browser cache since you are already looking at it, so it costs no extra download.

--David Göthberg (talk) 04:07, 26 November 2009 (UTC)

I mean non-SVGs. Things like File:SunBurst10.PNG, File:EFS_highres_STS066_STS066-101-39.JPG, File:St-Crepin.jpg, and File:TerraformedVenus.jpg are huge. Having thumbnails of intermediate size would allow people on low bandwidth connections to get a better look without a long wait. In addition, IE 6 or 7 won't even render an image at all beyond some predetermined limit (I think it was something like 25 megapixels but I'm not sure), which makes it hard for some people to look at the originals. Also, just as people might want to use an SVG rendered at various sizes, they also might want to use a JPG at a variety of scales. Yes that transition is lossy, but giving people easy access to images at a scale that is convenient to them would still aid in reuse. Basically, I'm of the opinion that most of the use cases for wanting multiple sizes for SVGs aren't unique to SVGs but could apply to a wider population of images. Dragons flight (talk) 07:56, 26 November 2009 (UTC)

Silly me, you are right. The operations I described above could just as well be used for getting a PNG version of an SVG, and I myself have sometimes done so. But as you point out, that is not so user-friendly. And as you say, providing more sizes is a good thing no matter what type of image it is. So I agree, we should add this for all the image formats that MediaWiki can resize. It seems MediaWiki resizes JPGs to JPG, and GIFs to GIF.

TheDJ & Co: Since there are not many GIFs around, so you won't have to search for it, here is one you can use for the testing: File:Edit-copy-purple.gif

--David Göthberg (talk) 09:35, 26 November 2009 (UTC)

Just a comment -- if implementing these thumbnails for non-SVG images, note that the ImageHandler for them (apparently?) ignores the height parameter, using it neither to cap the overall size (like the SVGs) nor to force the aspect ratio, so there is no point in specifying it in the URL. • Anakin 18:17, 26 November 2009 (UTC)

Right, the new and more robust way to get the image can't use a height parameter. (See TheDJ's 3rd version above.) But we can easily check the height to width ratio of the image from javascript and adjust the width values we use.

I have done some more testing and noticed something I had forgotten: Wikipedia can only rescale PNGs and JPGs (and indirectly SVGs). It doesn't rescale GIFs. So we will have to live without this feature for the GIF images.

--David Göthberg (talk) 03:23, 27 November 2009 (UTC)

Spellcheck in edit summary

Per a discussion at the Village pump, we (I and Dispenser) would like to turn on spellchecking in the edit summary field. At the moment this works for Firefox 2 and 3. At least for me it doesn't work in Opera, but it is likely more browsers will sooner or later support this. I would like to add the code below to MediaWiki:Common.js/edit.js:

// Turn on spellchecking in the edit summary field, for Firefox. 
// Temporary until [[bugzilla:21604]] is deployed
addOnloadHook( function() {
  var wpSummary = document.getElementById( "wpSummary" );
  if ( wpSummary && typeof wpSummary.spellcheck != undefined )
    wpSummary.spellcheck = true;
} );

The code has been checked (and fixed) by TheDJ.

--David Göthberg (talk) 16:40, 24 November 2009 (UTC)

I would support adding this to edit.js But it needs a comment with r59360 or the bugzilla number. Easier on maintenance in the future. —TheDJ (talk • contribs) 18:32, 24 November 2009 (UTC)

Agreed, it should have such a comment. By the way, it should be r59361, not r59360, but yeah bugzilla:21604 is better. How about this: "Remove this when MediaWiki adds "spellcheck = true" to the rendered pages. See [[bugzilla:21604]]." Since that gives a hint how to easily check if it has been deployed. I added it to the code above, feel free to modify the comment in the code.

--David Göthberg (talk) 01:38, 25 November 2009 (UTC)

A bit too verbose I think. I shortened it. —TheDJ (talk • contribs) 14:13, 25 November 2009 (UTC)

Your shorter version is okay too. So I have now added this to MediaWiki:Common.js/edit.js.

--David Göthberg (talk) 16:56, 25 November 2009 (UTC)

I'm not a techie, so forgive me if this is a daft comment. Spell checking in the edit summary may cause more problems than it solves. Lots of users deliberately use odd abbreviations in their edit summaries - will the spell checker automatically correct them, prompt (with a need for an extra click) the user, or just graphically highlight the error? IMHO only the last of these is good, and I hope you're going to tell me that's what it is... --Dweller (talk) 12:55, 26 November 2009 (UTC)

No worries, it only highlights. I use Firefox 2, and for me it just puts light red underlining on words with bad spelling, that's all. And I can right-click those words to get a list of suggestions to insert in its place. And with another click I can add the word to the dictionary, if I deem the word correct. So my spellchecker by now understands lots of WP abbreviations and the names of the templates I use. :)) With two clicks I can change what language the spellchecker in Firefox uses. Very convenient for me who is not a native English speaker and uses three languages. I assume it works the same in Firefox 3.

--David Göthberg (talk) 13:09, 26 November 2009 (UTC)

Splendid. That ends the irritating intervention of the person who doesn't understand these things. Thanks for bearing with me. --Dweller (talk) 13:46, 26 November 2009 (UTC)

There's a Firefox setting to turn on spellcheck for all text boxes. Go to about:config, search for layout.spellcheckDefault and set it to 2.[5] Rocket000 (talk) 01:28, 3 December 2009 (UTC)

Rocket000: Thanks for the tip. It worked in my Firefox 2, now I have spellchecking everywhere. :)) But we should of course keep the javascript fix for the edit summary field, since most users won't know how to do that setting themselves.

--David Göthberg (talk) 03:58, 3 December 2009 (UTC)

Accountcreator CSS

I intend to add code in Common.js that loads the new MediaWiki:Accountcreator.css, similar to how Common.js loads MediaWiki:Sysop.js which in turn loads MediaWiki:Sysop.css. I will also make it so MediaWiki:Sysop.css is loaded before the page is rendered.

The reason is that we are currently updating the editnotice system. We need to show some links that are normally hidden, but admins and accountcreators should see them. See discussion at Wikipedia talk:Editnotice#Navbar. I have added an explanation how the hiding and showing code should be used at MediaWiki talk:Common.css#Hidden items.

I want to load MediaWiki:Accountcreator.css and MediaWiki:Sysop.css before the page is rendered, otherwise the page and scrollbar will "jump" when the hidden links get visible after the page has been rendered. It works fine when I test it in my personal /monobook.js, but there is one detail that I can only test here (how the !window.disableSysopJS variable is affected by the load order). So first I will only add code for loading MediaWiki:Accountcreator.css and see what happens. Then I will know what changes I can do in the loading of MediaWiki:Sysop.js and MediaWiki:Sysop.css. I'll report here when I know more.

--David Göthberg (talk) 11:26, 6 January 2010 (UTC)

I have added the code for the accountcreators, and it works fine.

But as I thought, we can't check variables set by users, unless inside addOnloadHook(). We need to load MediaWiki:Sysop.css before page rendering, so that means we can't check !window.disableSysopJS for it. But as far as I know the reason for that variable is that Sysop.js interferes with some user scripts, but the Sysop.css should not be a problem for those users. And as far as I can see from searching for "disableSysopJS" only three admins use that setting. The most noticeable difference for those three admins will be that from now on they will see pink background in the edit window when editing protected pages, just like all other admins see. If they don't like that, then they can instead do like some of us and add one line of CSS to their /monobook.css to change that pink background to something else.

Since the code for loading the sysop and accountcreator files is so similar, I want to merge it, like this:

/** For sysops and accountcreators *****************************************
 *
 *  Description: Allows for sysop-specific Javascript at [[MediaWiki:Sysop.js]],
 *               and accountcreator-specific CSS at [[MediaWiki:Accountcreator.css]].
 */
if ( wgUserGroups ) {
  for ( var g = 0; g < wgUserGroups.length; ++g ) {
    if ( wgUserGroups[g] == "sysop" ) {
      importStylesheet("MediaWiki:Sysop.css");
      addOnloadHook( function() {
        if ( !window.disableSysopJS ) {
          importScript("MediaWiki:Sysop.js");
        }
      } );
    } 
    else if ( wgUserGroups[g] == "accountcreator" ) {
      importStylesheet("MediaWiki:Accountcreator.css");
    }
  }
}

This also makes it easy and efficient if we want to add loading of special CSS or javascript for other user groups.

--David Göthberg (talk) 12:03, 6 January 2010 (UTC)

Y Done - I have updated Common.js with the code above. Sysop.css is now loaded before page rendering.

--David Göthberg (talk) 13:25, 7 January 2010 (UTC)

The editnotice system now also needs to unhide a link when a user edits his own user or user talk page. That is, no one else than the user himself (and admins) should see it. See discussion at Wikipedia talk:Editnotice#User page links. To do that I intend to add this code to MediaWiki:Common.js/edit.js:

// Loads [[MediaWiki:Ownuserspace.css]] when the 
// user is on his own user or user talk basepage.
if ( (wgNamespaceNumber == 2 || wgNamespaceNumber == 3) && wgTitle == wgUserName ) {
  importStylesheet("MediaWiki:Ownuserspace.css");
}

The above code only loads MediaWiki:Ownuserspace.css when on the user's rootpage or root talk page, not on the user's subpages. Currently we don't need it to load on the subpages, so no reason to make the code more complicated. Later we might load it for the entire userspace, so I named the CSS file "userspace" instead of "userpage". And currently we only need it when editing the page, so loading it from /edit.js is more efficient than loading it from Common.js.

--David Göthberg (talk) 22:41, 12 January 2010 (UTC)

Y Done – --David Göthberg (talk) 01:33, 13 January 2010 (UTC)

 Undone - I have removed the loading of "MediaWiki:Ownuserspace.css" since not needed anymore. Amalthea pointed out that {{REVISIONUSER}} returns the name of the current user when it is used in system messages, which is a better solution for the editnotice system. See Wikipedia talk:Editnotice#User page links.

But we still use the javascript for sysops and accountcreators shown in the first code box above.

--David Göthberg (talk) 12:11, 14 January 2010 (UTC)

WikiMiniAtlas

I have noticed that meta:MediaWiki:Wikiminiatlas.js is loaded on every page view, no matter if a page has coordinates or not. I intend to make it so it only loads when needed. (All our other special scripts are only loaded when needed.)

Loading the WikiMiniAtlas code costs load time on the first page view, and it costs rendering time on every page view. (Some users still have slow connections and/or slow computers.) And it costs bandwidth for the Wikimedia servers to transfer that file. Last time I checked the stats the average visitor to Wikipedia only views five pages in one session, which means that many visitors don't view any pages with coordinates.

As far as I can see all coordinates here at the English Wikipedia are added by using the {{coord}} template. That template renders very differently in different situations, using different classes and ids. So I will add a CSS id we can trigger on at the beginning of that template, like this:

<span id="wikiminiatlas-load"></span>

And I will change the code in MediaWiki:Common.js that loads meta:MediaWiki:Wikiminiatlas.js to this:

addOnloadHook( function() {
  var wmaload = document.getElementById("wikiminiatlas-load");
  if ( !wmaload ) return;   //The page has no coordinates.

  if (wgServer == "https://secure.wikimedia.org") {
    var metaBase = "https://secure.wikimedia.org/wikipedia/meta";
  } else {
    var metaBase = "http://meta.wikimedia.org";
  }
  importScriptURI(metaBase+"/w/index.php?title=MediaWiki:Wikiminiatlas.js&action=raw&ctype=text/javascript&smaxage=21600&maxage=86400")
} );

I will notify the people who work with coordinates and Dschwen who seems to be the main coder of the WikiMiniAtlas system.

--David Göthberg (talk) 17:21, 15 January 2010 (UTC)

Wikiminiatlas is currently active for every geolink {{coor URL}}. That is every link that starts as http://stable.toolserver.org/geohack/geohack.php. I'm not sure we would want to complicate this system even further. Also, I note that there can be multiple coords on one page, so adding a unique id is not valid in that case. Adding a class makes the process more complicated however, because the getElementsByClassName (which is really slow on some browsers) will have to be run twice. —TheDJ (talk • contribs) 17:29, 15 January 2010 (UTC)

Agree with TheDJ here. As outlined abobe this is not a good approach. Let me think about it. --Dschwen 18:13, 15 January 2010 (UTC)

I am aware that there can be multiple coordinates on the same page. But adding the same id several times on a page is no problem since I only use it to trigger the loading, not as an anchor. And using an id is of course the best option since checking it is efficient.

TheDJ: Thanks for pointing out {{coor URL}}. It seems the trigger id should be added to that template instead.

--David Göthberg (talk) 18:30, 15 January 2010 (UTC)

It's not "no problem", it's invalid HTML. Both HTML4 and HTML5 require absolutely explicitly that the id value must be unique within the document. I assume you want to use an id instead of a class so you can use getElementById() rather than the more expensive getElementsByClassName(); tough. You can't break HTML validity just for the sake of a few miliseconds of JS execution time. I wouldn't be surprised if a lot of JS, Twinkle especially, broke entirely. Happy‑melon 18:51, 15 January 2010 (UTC)

My concern was also particularly for Twinkle. We've seen it stumble over broken HTML quite a few times already. —TheDJ (talk • contribs) 19:45, 15 January 2010 (UTC)

TheDJ and Happy-melon: As far as I know all web browsers handle multiple instances of ids nicely. And multiple ids are commonplace since it is such a common "mistake", so browsers must handle it. And it is commonplace here at Wikipedia too, since some templates that were originally meant to only be used once, and have an id, over time have come to be used more than once on some pages. And pages sometimes have the same section title or shortcut/anchor more than once on a page, which means the same ids are repeated. If Twinkle chokes on ids, then it is seriously broken and should be fixed.

Happy-melon: Running getElementsByClassName() isn't about milliseconds. On older computers we are talking many seconds, on every page load. Since the "Usability" project uses so inefficient code, among other things with several getElementsByClassName() calls, there now are pages here at Wikipedia that takes about one minute to load on older computers. I have such an old computer, I have had to adblock the "Usability" code in my browser to be able to continue to use Wikipedia.

That millions of Wikipedia users should unnecessary spend extra time to load pages because of the WikiMiniAtlas code is bad and should be fixed. Using an id is the simplest and most efficient way to fix it for pages that don't need the WikiMiniAtlas code.

But if you guys are so worried about ids, then I suggest you ask the devs to add a magic word that lets us add an id (or perhaps even other items) at multiple places in a page, but only renders the first of those items on the page.

--David Göthberg (talk) 21:23, 15 January 2010 (UTC)

At closer inspection, it doesn't even use getElementsByClassName. It just gets all the links on the page (which can be a lot of course). —TheDJ (talk • contribs) 22:43, 15 January 2010 (UTC)

What if we set a maximum allowed execution time on the script .... ? We could bail parsing A elements after 10 seconds for instance ? It would only handle as many coordinate links as it has been able to parse in that time. —TheDJ (talk • contribs) 22:45, 15 January 2010 (UTC)

DG: Saying "it's ok because web browsers seem to be alright with it" is like saying it's ok to use malformed HTML because we know Tidy cleans up after us: we don't jump through fire hoops to eliminate it because we have that safety net, but it's not just "ok" because we know that it has the potential to cause serious problems. You're normally a champion of not using outlandish hacks when they result in unstable code, I'm honestly surprised to see you so happy to do so here.

Can someone say whether the hasClass() function in our JS is genuinely significantly faster than the native getElementsByClassName(), and if so, is it possible to work the efficiency increase into the site version? I'll happily commit an improved native function if someone wants to write one. Happy‑melon 23:11, 15 January 2010 (UTC)

TheDJ: I didn't say that the WikiMiniAtlas code is using getElementsByClassName(). What I said is that we shouldn't use that function to decide whether to load the WikiMiniAtlas code or not, since that function is to slow.

Happy-melon: Using CSS ids is not an outlandish hack, instead it is a well working tool. That ids should just be used once is just the typical impossible to honour theoretical demand from the W3C people. They have many such weird demands that most web sites can't bother about. Wikipedia breaks the W3C standards in many places, since reality goes before theory. (But there is one W3C recommendation that web browsers do honour: They do graceful degrade.)

Note that Wikipedia pages now take 30-60 seconds to load on older computers. That's what this is about. Reading Wikipedia with a slow computer is now only barely acceptable. And it is no longer possible to edit Wikipedia if you have a slow computer, unless you have exceptional patience or know how to apply a whole bunch of blocks and fixes to make Wikipedia load faster. This might be one of the reasons why the number of editors is declining. (It is well known that many of our editors are unemployed, that's why they have time to edit, and unemployed people often can't afford to buy a new computer.) And we want Wikipedia to be used also in less developed countries.

We need to do anything we can to make Wikipedia useful for those that can't afford to buy the latest computers.

--David Göthberg (talk) 06:33, 16 January 2010 (UTC)

WMA loader rewrite

Looking at the WMA code, it is not as efficient as it could be. It includes a bunch of feature we don't or can't use here and translations for all the languages. If we make a lite version here, we could add a double pass feature (using a cache) that would disable it if there are too many coordinates on a page. — Dispenser 19:17, 15 January 2010 (UTC)

WMA loader lite

// WikiMiniAtlas loader lite
var wikiminiatlas = {
 config:
 {
  width     : 600,
  height    : 400,
  zoom      : -1,
  enabled   : true,
  onlytitle : false,
  iframeurl : 'http://stable.toolserver.org/wma/iframe.html',
  imgbase   : 'http://stable.toolserver.org/wma/tiles/'
 },
 link : null,
 bodyc : null,
 coordinates : 0,
 
 iframe : { div: null, iframe: null, closebutton: null },
 mapbutton: null,
 marker : { lat:0, lon:0 },
 
 coord_params: '',
 coord_filter: /^([\d+-.]+)_([\d+-.]*)_?([\d+-.]*)_?([NS])_([\d+-.]+)_([\d+-.]*)_?([\d+-.]*)_?([EOW])/,
 
 // vertikale position auf der Seite bestimmen
 totalOffset : function( obj, offset )
 {
  if( obj.offsetParent == null || 
      obj.offsetParent.id == 'content' )
   return offset + obj.offsetTop;
  else
   return wikiminiatlas.totalOffset(obj.offsetParent, offset+obj.offsetTop );
 },
 
 // move iframe around and toggle visibility
 toggleIFrame : function( mp, my ) {
  var newurl = wikiminiatlas.config.iframeurl + '?' + mp;
  with(wikiminiatlas.iframe) {
   if( iframe.src != newurl ) {
    iframe.src = newurl;
    div.style.top = (my || 0) + 'px';
    div.style.visibility="visible";
   } else {
    div.style.visibility=(div.style.visibility == "visible"?"hidden":"visible");
  }
  return false;
 },
 
 
 // Insert the IFrame into the page.
 loader : function() {
  // apply user settings
  if( typeof(wma_settings) == 'object' )
   for (var key in wma_settings) {
    if( typeof(wma_settings[key]) == typeof(wikiminiatlas.config[key]) )
     wikiminiatlas.config[key] = wma_settings[key];
   }
 
  with(wikiminiatlas) {
   bodyc = ( config.onlytitle ? document.getElementById('coordinates') : document.getElementById('bodyContent') || document);
   if( config.enabled == false ) return;
   if( bodyc == null ) return;
 
   var links = bodyc.getElementsByTagName('a');
   for( var key=0; (link = links[key])!=null; key++ ) {
    if(link.className!='external text'
     || link.href.indexOf('http://stable.toolserver.org/geohack/geohack.php?')==-1
     || link.href.test(/_globe:(?!earth)/i)) {
	 continue;
	}
    coord_params = link.href.match(/&params=([^&=<>|]{7,255})/);
    if(!coord_params) {
     continue;
    }
    coord_params = coord_params[1];
	  
    if(coord_filter.test(coord_params)) {
     coord_filter.exec(coord_params);
     marker.lat=(1.0*RegExp.$1) + ((RegExp.$2||0)/60.0) + ((RegExp.$3||0)/3600.0);
     if(RegExp.$4=='S') marker.lat*=-1;
     marker.lon=(1.0*RegExp.$5) + ((RegExp.$6||0)/60.0) + ((RegExp.$7||0)/3600.0);
     if(RegExp.$8=='W') marker.lon*=-1;
    }
 
	var zoomlevel = 1;
    // Find a sensible Zoom-level based on type
    if( coord_params.indexOf('_type:landmark') >= 0 ) zoomlevel = 8;
    else if( coord_params.indexOf('_type:city') >= 0 ) zoomlevel = 4;
    var ds_filter = /(dim|scale):([\d+-.]+)/;
    // If given use dim or scale for a zoomlevel
    if( ds_filter.test( clc ) )
    {
     ds_filter.exec(coord_params);
     // wma shows dim approx 4e7m at zoom 0 or 1.5e8 is the scale of zoomlevel 0
     zoomlevel = (RegExp.$1 == 'dim' ? Math.log( 4e7/RegExp.$2 ) : Math.log( 1.5e8/RegExp.$2 ) ) / Math.log( 2 );
     if( zoomlevel > 10 ) zoomlevel = 10;
    }
    if( config.zoom != -1 ) {
     var zoomlevel = config.zoom;
	}
 
    mapbutton = link.parentNode.insertBefore(document.createElement('img'), link);
    mapbutton.alt = ' ';
    mapbutton.className = 'noprint';
    mapbutton.title = 'show location on an interactive map';
    mapbutton.src = 'http://upload.wikimedia.org/wikipedia/commons/thumb/9/9a/Erioll_world.svg/18px-Erioll_world.svg.png'; //[[File:Erioll_world.svg]] 
    mapbutton.style.cssText = "padding:0px 3px 0px 0px; cursor:pointer;";
    mapbutton.mapparam = (new Arrary(marker.lat, marker.lon, config.width, config.height, 'en', zoomlevel, wgUserLanguage)).join('_')
    mapbutton.onclick = function() {
	 wikiminiatlas.toggleIFrame( this.mapparam, wikiminiatlas.totalOffset( this, 0 ) + 20; );
	 return true;
	};
   } //for
 
   // prepare iframe to house the map 
   if ( coord_params != null ) { // FIXME: don't assume param= exists
    iframe.div = document.createElement('div');
    iframe.div.style.width = (config.width+2)+'px';
    iframe.div.style.height = (config.height+2)+'px';
    iframe.div.style.cssText = 'visibility:hidden; margin:0px; padding:0px; backgroundColor:white; position:absolute; right:2em; top:1em; border:1px solid gray; z-index:13;';
 
    iframe.iframe = document.createElement('iframe');
    iframe.iframe.scrolling = 'no';
    iframe.iframe.frameBorder = '0';
    iframe.iframe.style.width = (config.width)+'px';
    iframe.iframe.style.height = (config.height)+'px';
    iframe.iframe.style.cssText = 'position:absolute; right:1px; top:1px; margin:0px; padding:0px; z-index:14;';
    iframe.div.appendChild(iframe.iframe);
	
    iframe.closebutton = iframe.div.appendChild(document.createElement('img'));
    iframe.closebutton.alt = '';
    iframe.closebutton.src = 'http://upload.wikimedia.org/wikipedia/commons/d/d4/Button_hide.png' // [[File:Button hide.png]]
    iframe.closebutton.style.cssText = 'z-Index:15; position:absolute; right:11px; top:9px; width:18px; cursor:pointer';
    iframe.closebutton.title = 'close';
    iframe.closebutton.mapparam = '';
    iframe.closebutton.onclick = toggleIFrame;
 
    var content = document.getElementById('content') || document.getElementById('mw_content') || document.body;
    content.insertBefore(iframe.div,content.childNodes[0]);
   }
  } //with
 } //function
}
addOnloadHook(wikiminiatlas.loader);
//

I was hoping to get the size a lot smaller, but I guess this will have to do. It is currently at approx. 150 lines/6 KB compared to the original 503 lines/16 KB.

• Eliminate languages (~100 lines/4 KB)
• Removed unimplemented functions
• Use the cssText property (all major browser support this)
• Figure out a way of using regexes to reduce the D/DM/DMS parser to ten lines
• Look at rewriting parts to use less code

This code is completely untested, hopefully it'll serve as a spring board for others. — Dispenser 21:33, 15 January 2010 (UTC)

Ok, let me say one thing first: forking is a bad idea. That being said, good idea with the new D/DM/DMS parsing. This should be moved to the WMA production code on meta. The res I'm not excited about. Sure, going from 503 to 150 lines sounds impressive, but I'd say it is about 100% irrelevant. The tokenization of a few hundred Javascript lines should be no factor in the overall execution speed in pretty much any browser. The fact that the code still has to iterate over all links remains unchanged. Having a central code repository and the easy maintainability that comes with it should have an infinitely higher priority. We used to have local copies of WMA on every wiki. It sucked. It was a maintenance hell. We dropped that for good reasons. Please do not bring it back. --Dschwen 23:44, 15 January 2010 (UTC)

My goal was 50 lines so I fell quite far from that. But if I rewrite it I'm pretty sure I can get it under 100. I purposely did not add in the caching feature since I did not want to change the feature set/current limitations. Now performance, from my experience with JavaScript, the slowest part is the attachment of the icons next to the links since most browser choose to re-render the page at this point. I haven't found a way to avoid this. The only solution that I have is to time it, and project the total time, if too high then abort. Finally, on maintenance, the thread is about incorporation at least part of the WMA loader script, my goal is to make it lean enough that we avoid the extra overhead of contacting another server. — Dispenser 03:28, 16 January 2010 (UTC)

Well, that addresses none of my points. Linenumbers is a completely irrelevant performance metric that may impress people who know pretty much nothing about programming. Forking the loader and have instances on every wiki is a maintenance nightmare. --Dschwen 14:58, 16 January 2010 (UTC)

I was looking at isMaplink() i'm guessing it's very inefficient for it's purpose. I think it's better to construct one regexp for the urls early on, and then match the title to that regexp, instead of doing many matches inside a for loop. That might bring a significant speedup. —TheDJ (talk • contribs) 22:15, 18 January 2010 (UTC)

I added a five second timeout to the script (clear cache to test). List of bridges on the National Register of Historic Places in Pennsylvania is a nice test case. In Google Chrome all coordinates are processed in a snap. Quite a shame that the other major browsers are left in the dust like this. --Dschwen 15:38, 19 January 2010 (UTC)

I ported Dispensers regexp over to the production code, removing the call to ismaplink. The speedup is, to my surprise, pretty much insignificant. The amount of coordinates that get processed within the 5sec timelimit increases a bit, but it is still only about a quarter of all coords in Firefox, while Google Chrome manages to process 100% of the coordinates on that page, even with the old code. --Dschwen 16:26, 19 January 2010 (UTC)

Another improvement might be to set the properties of the imagemap before inserting it into the visible DOM. That might avoid a few DOM updates. —TheDJ (talk • contribs) 17:02, 19 January 2010 (UTC)

And addHandler(imagemap, "click", hookFunct); should be used instead of onclick, because .onclick behaves unpredictably when multiple onclick are hooked. —TheDJ (talk • contribs) 17:06, 19 January 2010 (UTC)

Which onclick are you referring to. In principle I agree about addHandler, but in the WMA, I know that by design only one click handler exists for each button. No need to use the slower addHandler. Will try your other suggestion about the DOM updates. --Dschwen 17:54, 19 January 2010 (UTC)

Ok, not feasable. The hookUpMapbutton function does not perform visible DOM changes, so there is no reason for a slowdown (other than the browser developers being just plain dumb). Furthermore hookUpMapbutton accesses the position of the element on the page, and to obtain that the element needs to be hooked into the document. --Dschwen 17:54, 19 January 2010 (UTC)

I realize now that I was looking at the old version apparently. Current is much better. —TheDJ (talk • contribs) 19:27, 19 January 2010 (UTC)