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)

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)