MediaWiki talk:Common.js/Archive 17

Archive 10

←

Archive 15

Archive 16

Archive 17

Archive 18

Archive 19

Archive 20

"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 Template:Bug, 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?utm_source=enwiki_00&utm_medium=anon_donation_banner&utm_campaign=spontaneous_donation" class="extiw" title="wikimedia:Fundraising"><b>continued donations</b></a> keep Wikipedia running!'; message[1]='<a href="http://wikimediafoundation.org/wiki/Donate/Now/en?utm_source=enwiki_01&utm_medium=anon_donation_banner&utm_campaign=spontaneous_donation" 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?utm_source=enwiki_02&utm_medium=anon_donation_banner&utm_campaign=spontaneous_donation" 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?utm_source=enwiki_03&utm_medium=anon_donation_banner&utm_campaign=spontaneous_donation" class="extiw" title="foundation:Fundraising"><b>supporting it financially</b></a>.'; message[4]='You can <a href="http://wikimediafoundation.org/wiki/Donate/Now/en?utm_source=enwiki_04&utm_medium=anon_donation_banner&utm_campaign=spontaneous_donation" 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?utm_source=enwiki_05&utm_medium=anon_donation_banner&utm_campaign=spontaneous_donation" class="extiw" title="foundation:Fundraising"><b>donating today</b></a>!'; message[6]='<a href="/wiki/Wikipedia:Researching_with_Wikipedia" title="Wikipedia:Researching with Wikipedia">Learn more about using Wikipedia for research.</a>'; message[7]='<a href="/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="/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="/wiki/Wikipedia:Citing_Wikipedia" title="Wikipedia:Citing Wikipedia">Learn more about citing Wikipedia.</a>'; message[10]='Have questions? <a href="/wiki/Wikipedia:Questions" title="Wikipedia:Questions">Find out how to ask questions and get answers.</a>'; message[11]='<a href="/wiki/Wikipedia:Basic_navigation" title="Wikipedia:Basic navigation">Find out more about navigating Wikipedia and finding information.</a>'; message[12]='<a href="/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)