MediaWiki talk:Common.js/Archive 17: Difference between revisions
Content deleted Content added
MiszaBot II (talk | contribs) m Archiving 2 thread(s) from MediaWiki talk:Common.js. |
Substituted template per Wikipedia:Templates for discussion/Log/2022 October 11#Template:Site JS editnotice. |
||
| (11 intermediate revisions by 8 users not shown) | |||
Line 18:
::: Also, I'll point you to this [[Wikipedia:Village_pump_(technical)#portable_devices|Village Pump Thread]] ... and you start to see why we started a redirect. --[[User:Hcatlin|Hampton]] ([[User talk:Hcatlin|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 ). <span style=white-space:nowrap>「[[User:Dinoguy1000|<span style=color:#00f>ダイノ</span><span style=color:#080>ガイ</span>]][[Special:Contributions/Dinoguy1000|<span style=color:#F90>千？！</span>]]」<sup>[[Help:JP|?]] · [[User talk:Dinoguy1000|<small style=font-weight:normal>Talk⇒Dinoguy1000
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. --[[User:Hcatlin|Hampton]] ([[User talk:Hcatlin|talk]]) 21:19, 30 July 2009 (UTC)
:Thank you for leaving a note on the talk page. :-) --[[User:MZMcBride|MZMcBride]] ([[User talk: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). =) <span style=white-space:nowrap>「[[User:Dinoguy1000|<span style=color:#00f>ダイノ</span><span style=color:#080>ガイ</span>]][[Special:Contributions/Dinoguy1000|<span style=color:#F90>千？！</span>]]」<sup>[[Help:IJP|?]] · [[User talk:Dinoguy1000#top|Talk⇒Dinoguy1000]]</sup
== More functional breakdown ==
Following the 2008 discussion [[MediaWiki talk:Common.js/Archive 14#Functional breakdown by size|Functional breakdown by size]] when <
: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. [[User:Ale_jrb|<
::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. —[[User:Remember the dot|Remember the dot]] <sup>([[User talk:Remember the dot|talk]])</sup> 05:37, 26 June 2009 (UTC)
Line 38:
:To me, the problem is that we use way too much JavaScript. [[MediaWiki:Common.js/search.js|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. —[[User:Remember the dot|Remember the dot]] <sup>([[User talk:Remember the dot|talk]])</sup> 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. [[User:Ale_jrb|<
:::The IPv6 code was broken for Vector and other skins not compatible with Monobook. I have [http://en.wikipedia.org/w/index.php?title=MediaWiki%3ACommon.js%2FIPv6.js&diff=301855502&oldid=301160829 repaired this]. Mark is currently looking as to why the [http://ipv6and4.labs.wikimedia.org/ 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. —[[User:TheDJ|Th<span style="color: green">e</span>DJ]] ([[User talk:TheDJ|talk]] • [[Special:Contributions/TheDJ|contribs]]) 13:34, 13 July 2009 (UTC)
Line 52:
: Someone apparently forgot what he wrote [[Wikipedia:Editing the interface|here]] ;) —''[[User:Ruud Koot|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? <
:::I obliged! =D <span style=white-space:nowrap>「[[User:Dinoguy1000|<span style=color:#00f>ダイノ</span><span style=color:#080>ガイ</span>]][[Special:Contributions/Dinoguy1000|<span style=color:#F90>千？！</span>]]」<sup>[[Help:IJP|?]] · [[User talk:Dinoguy1000|<small style=font-weight:normal>Talk⇒Dinoguy1000
:::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. --[[User:MZMcBride|MZMcBride]] ([[User talk:MZMcBride|talk]]) 19:01, 14 July 2009 (UTC)
Line 66:
: 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 —''[[User:Ruud Koot|Ruud]]'' 22:48, 14 July 2009 (UTC)
::How about
{{fmbox
| type = editnotice
| image = [[File:Finger pointing.jpg|60px]]
| text = There is no such thing as a 'trivial' or 'unnoticeable' change to the site JavaScript. Test the ''exact'' change on IE, Firefox, Safari and Chrome, ''twice'' (since you'll have forgotten to get the recached files the first time), because [[sod's law]] says you'll break something if you don't. Save yourself the [[Wikipedia:Whacking with a Wet Trout|embarrassment]] and [[Wikipedia:Village stocks|humiliation]]. Discuss your changes on the [[{{TALKPAGENAME}}|talk page]] before implementing them.
}}
::?? [[User:Happy-melon|<b color="forestgreen">Happy</b>]]‑[[User talk:Happy-melon|<b color="darkorange">melon</b>]] 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. [[User:Ale_jrb|<span style="color: green">A</span><small><span style="color: green">le_Jrb</span></small>]]<sup>[[User_talk:Ale_jrb|<span style="color: blue">talk</span>]]</sup> 13:08, 17 July 2009 (UTC)
::::Same here. Give me a minute, and I'll tweak the wording, too. =) <span style=white-space:nowrap>「[[User:Dinoguy1000|<span style=color:#00f>ダイノ</span><span style=color:#080>ガイ</span>]][[Special:Contributions/Dinoguy1000|<span style=color:#F90>千？！</span>]]」<sup>[[Help:IJP|?]] · [[User talk:Dinoguy1000#top|Talk⇒Dinoguy1000]]</sup></span> 18:52, 17 July 2009 (UTC)
== border="1" in tables ==
Last year we [http://en.wikipedia.org/w/index.php?title=MediaWiki:Common.js/edit.js&diff=233046900&oldid=226600579 hacked] the formatting of wikitables to help them appear with borders when rendering in environments without CSS (see [[MediaWiki_talk:Common.css/Archive_5#Wikitable_borders_without_CSS|discussion]]). Now that is coming round to bite us: with the recent wikitech-l thread supporting a move to [[HTML 5]] ([http://lists.wikimedia.org/pipermail/wikitech-l/2009-July/043865.html] and subsequent), we now have a horde of markup on enwiki that is going to become ''invalid'' [http://lists.wikimedia.org/pipermail/wikitech-l/2009-July/043865.html]; see the extensive discussion at {{
I don't think we should give ourselves the task of removing existing invalid attributes at this stage (things like <
*I agree, no point in leaving that in. —[[User:TheDJ|Th<span style="color: green">e</span>DJ]] ([[User talk:TheDJ|talk]] • [[Special:Contributions/TheDJ|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**. — [[User:Dispenser|Dispenser]] 11:29, 24 July 2009 (UTC)
*:''Ouch'' <
*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.<br>But anyway, yes, removing <code>border="1"</code> in anticipation sounds like a good idea. I'd suggest adding a rule to remove <code>border</code>, <code>cellpadding</code>, <code>cellspacing</code>, etc. to the AWB general fixes before long, too.<br>[[User talk:Amalthea|<span style="font-variant:small-caps;color:#832">Amalthea</span>]] 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.<br/><code>class="wikitable" border="1"</code> 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. [[User:Also-Happy-melon|<small style="color:red">(also)</small>]][[User:Happy-melon|<span style="color:forestgreen">'''Happy'''</span>]]‑[[User talk:Happy-melon|<span style="color:darkorange">'''melon'''</span>]] 12:58, 24 July 2009 (UTC)
Line 111 ⟶ 115:
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 {{tl|db-user}} with a quick edit after a confirmation dialog. Any thoughts? --[[User:MZMcBride|MZMcBride]] ([[User talk: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. <span style=white-space:nowrap>「[[User:Dinoguy1000|<span style=color:#00f>ダイノ</span><span style=color:#080>ガイ</span>]][[Special:Contributions/Dinoguy1000|<span style=color:#F90>千？！</span>]]」<sup>[[Help:IJP|?]] · [[User talk:Dinoguy1000#top|Talk⇒Dinoguy1000]]</sup></span> 18:26, 19 October 2009 (UTC)
== How to insert a ＜br＞ in the toolbar? ==
Line 120 ⟶ 124:
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? --[[User:MZMcBride|MZMcBride]] ([[User talk: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. <
::Now we just a javascript implementation of the parser and we'll be set! — [[User:RockMFR|RockMFR]] 23:20, 27 October 2009 (UTC)
Line 129 ⟶ 133:
So we'll add "needs a code rewrite" to the list of reasons I've now [http://en.wikipedia.org/w/index.php?title=MediaWiki:Monobook.js&diff=prev&oldid=322588403 removed] the banner. Copied below for posterity and for improvements. --[[User:MZMcBride|MZMcBride]] ([[User talk:MZMcBride|talk]]) 19:26, 28 October 2009 (UTC)
{{collapse top}}
<
/** Anon tips and donation banner **************************
*
Line 141 ⟶ 145:
if(wgUserName == null) addOnloadHook((function (){
var message=new Array();
message[0]='Your <a href="http://wikimediafoundation.org/wiki/Donate/Now/en
message[1]='<a href="http://wikimediafoundation.org/wiki/Donate/Now/en
message[2]='Wikipedia is sustained by people like you. Please <a href="http://wikimediafoundation.org/wiki/Donate/Now/en
message[3]='Help us improve Wikipedia by <a href="http://wikimediafoundation.org/wiki/Donate/Now/en
message[4]='You can <a href="http://wikimediafoundation.org/wiki/Donate/Now/en
message[5]='Help us provide free content to the world by <a href="http://wikimediafoundation.org/wiki/Donate/Now/en
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>';
Line 170 ⟶ 174:
}
}));
</syntaxhighlight>
{{collapse bottom}}
Line 178 ⟶ 182:
I think we could simplify this code from the function ''toggleNavigationBar''
<
if ( hasClass( NavChild, 'NavPic' ) ) {
NavChild.style.display = 'none';
Line 185 ⟶ 189:
NavChild.style.display = 'none';
}
</syntaxhighlight>
to
<
if ( hasClass( NavChild, 'NavPic' ) || hasClass( NavChild, 'NavContent') ) {
NavChild.style.display = 'none';
}
</syntaxhighlight>
and this one
<
if (hasClass(NavChild, 'NavPic')) {
NavChild.style.display = 'block';
Line 201 ⟶ 205:
NavChild.style.display = 'block';
}
</syntaxhighlight>
to
<
if (hasClass(NavChild, 'NavPic') || hasClass(NavChild, 'NavContent')) {
NavChild.style.display = 'block';
}
</syntaxhighlight>
What do you think? [[User:Heldergeovane|Helder]] ([[User talk:Heldergeovane|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. —[[User:TheDJ|Th<span style="color: green">e</span>DJ]] ([[User talk:TheDJ|talk]] • [[Special:Contributions/TheDJ|contribs]]) 19:49, 29 October 2009 (UTC)
::Or maybe all this part
<
// if shown now
if (NavToggle.firstChild.data == NavigationBarHide) {
Line 237 ⟶ 241:
NavToggle.firstChild.data = NavigationBarHide;
}
</syntaxhighlight>
::could be changed to
<
for (var NavChild = NavFrame.firstChild; NavChild != null; NavChild = NavChild.nextSibling) {
if (hasClass(NavChild, 'NavPic') || hasClass(NavChild, 'NavContent')) {
Line 245 ⟶ 249:
}
}
</syntaxhighlight>
::It seems a lot simpler, isn't? ;-) [[User:Heldergeovane|Helder]] ([[User talk:Heldergeovane|talk]]) 18:20, 30 October 2009 (UTC)
:::Add the forgotten <code>NavToggle.firstChild.data = ...</code> 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". — [[user:Alex Smotrov|AlexSm]] 19:31, 30 October 2009 (UTC)
Line 251 ⟶ 255:
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. [[User:Cacycle|Cacycle]] ([[User talk: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? <span style=white-space:nowrap>「[[User:Dinoguy1000|<span style=color:#00f>ダイノ</span><span style=color:#080>ガイ</span>]][[Special:Contributions/Dinoguy1000|<span style=color:#F90>千？！</span>]]」<sup>[[Help:IJP|?]] · [[User talk:Dinoguy1000#top|Talk⇒Dinoguy1000]]</sup></span> 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 <code>javascript:void(importScript('User:Cacycle/myskinify.js'))</code> in your browser's address bar while on this page to see what it does.<br>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. [[User talk:Amalthea|<span style="font-variant:small-caps;color:#832">Amalthea</span>]] 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')
</syntaxhighlight>
:P.S. Could you please elaborate on the "upcoming change to vector"? — [[user:Alex Smotrov|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. [[User talk:Amalthea|<span style="font-variant:small-caps;color:#832">Amalthea</span>]] 19:21, 16 October 2009 (UTC)
Line 264 ⟶ 268:
:: 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. [[User:Cacycle|Cacycle]] ([[User talk: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 <
:::Vector skin is only a part of beta interface, and it's possible it will stay optional unlike beta toolbar. — [[user:Alex Smotrov|AlexSm]] 20:25, 16 October 2009 (UTC)
Line 272 ⟶ 276:
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 :-) [[User:Cacycle|Cacycle]] ([[User talk:Cacycle|talk]]) 00:24, 17 October 2009 (UTC)
: Check this: <
:: Any opinions against adding these few lines of code to Common.js? [[User:Cacycle|Cacycle]] ([[User talk: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. [[User:Ale_jrb|<
:::: 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. [[User:Cacycle|Cacycle]] ([[User talk:Cacycle|talk]]) 21:58, 29 October 2009 (UTC)
::::: Added. [[User:Cacycle|Cacycle]] ([[User talk:Cacycle|talk]]) 16:30, 31 October 2009 (UTC)
Line 301 ⟶ 305:
if (/(Android|iPhone|iPod|webOS|NetFront|Opera Mini|SEMC-Browser|PlayStation Portable|Nintendo Wii|SymbianOS)/.test(navigator.userAgent)) {
<small><span class="autosigned">—Preceding [[Wikipedia:Signatures|unsigned]] comment added by [[User:Grille Chompa|Grille Chompa]] ([[User talk:Grille Chompa|talk]] • [[Special:Contributions/Grille Chompa|contribs]]) </span></small><!-- Template:Unsigned -->
:Please allow time for discussion before placing editprotected requests. Thanks. — Martin <small>([[User:MSGJ|MSGJ]] · [[User talk:MSGJ|talk]])</small> 12:22, 8 November 2009 (UTC)
::Support was explicitly [http://en.wikipedia.org/w/index.php?title=MediaWiki%3ACommon.js&action=historysubmit&diff=321020280&oldid=320989816 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. —[[User:TheDJ|Th<span style="color: green">e</span>DJ]] ([[User talk:TheDJ|talk]] • [[Special:Contributions/TheDJ|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:
# We use wikitext, not (X)HTML. The fact that wikitext borrows some HTML tags doesn't change this.
# One of the points of wikitext is to be simpler than (X)HTML and its cruft.
# 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.
# 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.)
# '''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 [http://mobile.wikipedia.org/ Mobile.wikipedia.org] uses plain HTML 4.
# <br> looks nicer (it's punctuated symmetrically).
• [[User:Anakin101|Anakin]] <sup>[[User talk:Anakin101|(talk)]]</sup> 01:57, 10 November 2009 (UTC)
:I agree with Anakin, the line break button [[File:Button enter.png|23px]] in the edit toolbar should insert <code><br></code>, not <code><br /></code>. 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, <code><nowiki><br></nowiki></code> is the correct "HTML wikimarkup". But MediaWiki was updated to also understand <code><nowiki><br /></nowiki></code> 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 <code><nowiki><br \>, <br\>, </br>, </ br>, <\br> and <\ br></nowiki></code> all are faulty variants. And the variant <code><nowiki><br/></nowiki></code> (without space) is not a recommended variant of the <code><nowiki><br /></nowiki></code> tag, according to the [[World Wide Web Consortium|World Wide Web Consortium (W3C)]], since it breaks older web browsers.
:So I suggest we stick to the simple wikimarkup <code><nowiki><br></nowiki></code> tag and not change all our [[Special:Statistics|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 <code><nowiki><br \></nowiki></code>.
:In April 2009 Brion Vibber, lead developer of MediaWiki, [http://techblog.wikimedia.org/2009/04/skin-js-cleanup-and-jquery/ 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 <code><br /></code> in wiki code to <code><br></code> in the rendered pages. Again, wikimarkup is not the same thing as rendered page code.
:--[[User:Davidgothberg|David Göthberg]] ([[User talk:Davidgothberg|talk]]) 05:18, 10 November 2009 (UTC)
:A few comments:
:# I would argue that "best practice" is to use <br />, not <br>;
:# 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;
:# 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;
:# 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;
:# 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. --[[User:MZMcBride|MZMcBride]] ([[User talk: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.[http://www.w3.org/TR/html5/semantics.html#the-br-element] but, we currently set the DOCTYPE to XHTML 1.0 Transitional, where <br /> is correct. ---'''''— [[User:Gadget850|<span style="color:gray">Gadget850 (Ed)</span>]]<span style="color:darkblue"> </span>'''''<sup>[[User talk:Gadget850|''talk'']]</sup> 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 <nowiki><br> into <br /></nowiki>. 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. —[[User:TheDJ|Th<span style="color: green">e</span>DJ]] ([[User talk:TheDJ|talk]] • [[Special:Contributions/TheDJ|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]]. [[User:Cacycle|Cacycle]] ([[User talk: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 <code><br /></code> 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?
:* <code><nowiki>'''Bold'''</nowiki></code>
:* <code><nowiki><b>Bold</b></nowiki></code>
:* <code><span style="font-weight:bold;">Bold</span></code>
:As far as I know <code><nowiki>'''bold'''</nowiki></code> is the one we recommend for '''bold''' text, while the span markup is the one that W3C recommends. <code><nowiki>'''Bold'''</nowiki></code> is also the markup currently used by the bold text button [[File:Button bold.png|23px]] in the edit toolbar. <code><nowiki>'''Bold'''</nowiki></code> 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.
:--[[User:Davidgothberg|David Göthberg]] ([[User talk:Davidgothberg|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. —[[User:TheDJ|Th<span style="color: green">e</span>DJ]] ([[User talk:TheDJ|talk]] • [[Special:Contributions/TheDJ|contribs]]) 21:03, 10 November 2009 (UTC)
<nowiki><br></nowiki> 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. <span style="font-family:Broadway">[[User:Mr.Z-man|Mr.]][[User talk:Mr.Z-man|'''''Z-'''man'']]</span> 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 <code><br></code> is easier to learn and use than <code><br /></code>.
:--[[User:Davidgothberg|David Göthberg]] ([[User talk:Davidgothberg|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. ---'''''— [[User:Gadget850|<span style="color:gray">Gadget850 (Ed)</span>]]<span style="color:darkblue"> </span>'''''<sup>[[User talk:Gadget850|''talk'']]</sup> 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>. <span style="font-family: verdana;"> — [[User:Edokter|<span style="color: #008;"><b><i>E</i>dokter</b></span>]] • [[User_talk:Edokter|<span style="color: #080;">Talk</span>]] • </span> 02:17, 11 November 2009 (UTC)
My personal opinion is that <nowiki><br></nowiki> is the right tag to encourage users to use, as it is free of unnecessary frills. Right now the parser automagically converts <nowiki><br></nowiki> to <nowiki><br /></nowiki> to satisfy XHTML 1. In the near future we will be moving to HTML 5, and then I assume the parser will automagically convert <nowiki><br /></nowiki> to <nowiki><br></nowiki>, 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, <nowiki><br></nowiki> 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. [[User:Dragons flight|Dragons flight]] ([[User talk: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. <samp><nowiki><br></nowiki></samp> is cleaner and easier to understand than <samp><nowiki><br /></nowiki></samp>, 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?" [[User:Happy-melon|<span style="color:forestgreen">'''Happy'''</span>]]‑[[User talk:Happy-melon|<span style="color:darkorange">'''melon'''</span>]] 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 <nowiki><br></nowiki> is the easier. [[User:Heldergeovane|Helder]] ([[User talk:Heldergeovane|talk]]) 22:45, 10 November 2009 (UTC)
:::TheDJ: The usage of <code><br /></code> confuses the editors. They often add for instance <code></br></code> or <code><br\></code>, which is invalid markup. Like in the wikitable here: [{{fullurl:Digital radio in Australia|action=edit&oldid=319596520§ion=3}}]. Using <code><br></code> 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 <code><br /></code>. But that is not an argument against using better markup, instead it means those tools should be fixed.
:::--[[User:Davidgothberg|David Göthberg]] ([[User talk:Davidgothberg|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... ---'''''— [[User:Gadget850|<span style="color:gray">Gadget850 (Ed)</span>]]<span style="color:darkblue"> </span>'''''<sup>[[User talk:Gadget850|''talk'']]</sup> 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 <nowiki><br></nowiki> 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. [[User:Dragons flight|Dragons flight]] ([[User talk: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.) --[[User:MZMcBride|MZMcBride]] ([[User talk: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. <span style="font-family: verdana;"> — [[User:Edokter|<span style="color: #008;"><b><i>E</i>dokter</b></span>]] • [[User_talk:Edokter|<span style="color: #080;">Talk</span>]] • </span> 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 {{tl|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 [http://svn.wikimedia.org/viewvc/mediawiki/trunk/phase3/includes/Sanitizer.php?view=markup '''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. • [[User:Anakin101|Anakin]] <sup>[[User talk:Anakin101|(talk)]]</sup> 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]]. —[[User:TheDJ|Th<span style="color: green">e</span>DJ]] ([[User talk:TheDJ|talk]] • [[Special:Contributions/TheDJ|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 <samp>wgUserName</samp> is null. [[User:Umherirrender|Der Umherirrende]] 16:34, 11 November 2009 (UTC)
:Yikes, will fix immediately —[[User:TheDJ|Th<span style="color: green">e</span>DJ]] ([[User talk:TheDJ|talk]] • [[Special:Contributions/TheDJ|contribs]]) 16:36, 11 November 2009 (UTC)
::Error avoided, but a more elegant approach might be needed for anon users. —[[User:TheDJ|Th<span style="color: green">e</span>DJ]] ([[User talk:TheDJ|talk]] • [[Special:Contributions/TheDJ|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 ([[:File:1LT BNC.svg|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 [[Commons:MediaWiki talk:Common.js#SVG files: links to rendered PNG images|talk page]]). --[[User:Leyo|Leyo]] 18:14, 12 November 2009 (UTC)
<syntaxhighlight lang="javascript">
// 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);
}
});
</syntaxhighlight>
: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. —[[User:TheDJ|Th<span style="color: green">e</span>DJ]] ([[User talk:TheDJ|talk]] • [[Special:Contributions/TheDJ|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.
::--[[User:Davidgothberg|David Göthberg]] ([[User talk:Davidgothberg|talk]]) 01:11, 25 November 2009 (UTC)
Code prepared in [[MediaWiki:Common.js/file.js]]. To be loaded from Common.js with:
<syntaxhighlight lang=javascript>
if( wgNamespaceNumber == 6 )
importScript('MediaWiki:Common.js/file.js');
</syntaxhighlight>
Most suggestions by David incorporated. I was wondering. Isn't "resolutions" a misnomer ? Perhaps we should just say "in different sizes" —[[User:TheDJ|Th<span style="color: green">e</span>DJ]] ([[User talk:TheDJ|talk]] • [[Special:Contributions/TheDJ|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? :))
:--[[User:Davidgothberg|David Göthberg]] ([[User talk:Davidgothberg|talk]]) 16:35, 25 November 2009 (UTC)
::{{done}} Deployed —[[User:TheDJ|Th<span style="color: green">e</span>DJ]] ([[User talk:TheDJ|talk]] • [[Special:Contributions/TheDJ|contribs]]) 17:50, 25 November 2009 (UTC)
Hmm, JavaScript can do ''loops'', if you get what I mean... — [[user:Alex Smotrov|AlexSm]] 20:43, 25 November 2009 (UTC)
<syntaxhighlight lang=javascript>
// 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 );
</syntaxhighlight>
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. — [[User:Dispenser|Dispenser]] 21:06, 25 November 2009 (UTC)
:I fixed the paths immediately, I think that was kinda important. —[[User:TheDJ|Th<span style="color: green">e</span>DJ]] ([[User talk:TheDJ|talk]] • [[Special:Contributions/TheDJ|contribs]]) 21:14, 25 November 2009 (UTC)
::The list of appends is messy. Put them in an array and iterate? [[User:Ale_jrb|<span style="color: green">A</span><small><span style="color: green">le_Jrb</span></small>]]<sup>[[User_talk:Ale_jrb|<span style="color: blue">talk</span>]]</sup> 21:17, 25 November 2009 (UTC)
::By that I mean the size, in case it isn't obvious. :) [[User:Ale_jrb|<span style="color: green">A</span><small><span style="color: green">le_Jrb</span></small>]]<sup>[[User_talk:Ale_jrb|<span style="color: blue">talk</span>]]</sup> 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. —[[User:TheDJ|Th<span style="color: green">e</span>DJ]] ([[User talk:TheDJ|talk]] • [[Special:Contributions/TheDJ|contribs]]) 21:40, 25 November 2009 (UTC)
::::No, it doesn't matter much. Significantly better practise though. Meh. :) [[User:Ale_jrb|<span style="color: green">A</span><small><span style="color: green">le_Jrb</span></small>]]<sup>[[User_talk:Ale_jrb|<span style="color: blue">talk</span>]]</sup> 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) —[[User:TheDJ|Th<span style="color: green">e</span>DJ]] ([[User talk:TheDJ|talk]] • [[Special:Contributions/TheDJ|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.)
::--[[User:Davidgothberg|David Göthberg]] ([[User talk:Davidgothberg|talk]]) 04:20, 26 November 2009 (UTC)
:::Using such local id eliminates all users with non-en language in preferences. — [[user:Alex Smotrov|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. —[[User:TheDJ|Th<span style="color: green">e</span>DJ]] ([[User talk:TheDJ|talk]] • [[Special:Contributions/TheDJ|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 :-( ) • [[User talk:Anakin101|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. —[[User:TheDJ|Th<span style="color: green">e</span>DJ]] ([[User talk:TheDJ|talk]] • [[Special:Contributions/TheDJ|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. —[[User:TheDJ|Th<span style="color: green">e</span>DJ]] ([[User talk:TheDJ|talk]] • [[Special:Contributions/TheDJ|contribs]]) 00:29, 27 November 2009 (UTC)
<syntaxhighlight lang="javascript">
// 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 )
</syntaxhighlight>
: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.
:--[[User:Davidgothberg|David Göthberg]] ([[User talk:Davidgothberg|talk]]) 02:59, 27 November 2009 (UTC)
:That code works, but might I suggest this alteration:
<syntaxhighlight lang="javascript">
var thumbu = file.getElementsByTagName('img')[0].src;
if (!thumbu) return;
function svgAltSize(w, title) {
var path = thumbu.replace(/\/\d+(px-[^\/]+$)/, "/" + w + "$1");
</syntaxhighlight>
: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., <nowiki>http://upload.wikimedia.org/wikipedia/en/thumb/3/35/200px-stupid-file-name.svg/200px-200px-stupid-file-name.svg.png</nowiki>. Also the wgTitle logic could be shortened to the more elegant <samp>wgTitle.match(/\.svg$/i)</samp> if you wish. • [[User talk:Anakin101|Anakin]] 03:13, 27 November 2009 (UTC)
::Deployed with suggestions. —[[User:TheDJ|Th<span style="color: green">e</span>DJ]] ([[User talk:TheDJ|talk]] • [[Special:Contributions/TheDJ|contribs]]) 23:13, 27 November 2009 (UTC)
:::And as usual, the new version works in all three of my browsers.
:::--[[User:Davidgothberg|David Göthberg]] ([[User talk:Davidgothberg|talk]]) 03:20, 28 November 2009 (UTC)
::::It is also deployed on Commons now. —[[User:TheDJ|Th<span style="color: green">e</span>DJ]] ([[User talk:TheDJ|talk]] • [[Special:Contributions/TheDJ|contribs]]) 13:26, 28 November 2009 (UTC)
:::::What do you think about [http://commons.wikimedia.org/w/index.php?diff=prev&oldid=32586541 this change]? Should it be implemented here, too? --[[User:Leyo|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? [[User:Dragons flight|Dragons flight]] ([[User talk: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.
:--[[User:Davidgothberg|David Göthberg]] ([[User talk:Davidgothberg|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. [[User:Dragons flight|Dragons flight]] ([[User talk: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]]
:::--[[User:Davidgothberg|David Göthberg]] ([[User talk:Davidgothberg|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. • [[User talk:Anakin101|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.
:--[[User:Davidgothberg|David Göthberg]] ([[User talk:Davidgothberg|talk]]) 03:23, 27 November 2009 (UTC)
== Spellcheck in edit summary ==
Per [[Wikipedia:Village pump (technical)#Turn on spellcheck in summary field|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]]:
<syntaxhighlight lang="javascript">
// 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;
} );
</syntaxhighlight>
The code has been checked (and fixed) by TheDJ.
--[[User:Davidgothberg|David Göthberg]] ([[User talk:Davidgothberg|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. —[[User:TheDJ|Th<span style="color: green">e</span>DJ]] ([[User talk:TheDJ|talk]] • [[Special:Contributions/TheDJ|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 <nowiki>[[bugzilla:21604]]</nowiki>.''" 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.
::--[[User:Davidgothberg|David Göthberg]] ([[User talk:Davidgothberg|talk]]) 01:38, 25 November 2009 (UTC)
:::A bit too verbose I think. I shortened it. —[[User:TheDJ|Th<span style="color: green">e</span>DJ]] ([[User talk:TheDJ|talk]] • [[Special:Contributions/TheDJ|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]].
::::--[[User:Davidgothberg|David Göthberg]] ([[User talk:Davidgothberg|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... --[[User:Dweller|Dweller]] ([[User talk: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.
:--[[User:Davidgothberg|David Göthberg]] ([[User talk:Davidgothberg|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. --[[User:Dweller|Dweller]] ([[User talk: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 <code>layout.spellcheckDefault</code> and set it to <code>2</code>.[http://kb.mozillazine.org/Layout.spellcheckDefault] [[User:Rocket000|Rocket000]] ([[User talk: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.
:--[[User:Davidgothberg|David Göthberg]] ([[User talk:Davidgothberg|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 <code>!window.disableSysopJS</code> 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.
--[[User:Davidgothberg|David Göthberg]] ([[User talk:Davidgothberg|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 <code>!window.disableSysopJS</code> 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:
<syntaxhighlight lang="javascript">
/** 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");
}
}
}
</syntaxhighlight>
:This also makes it easy and efficient if we want to add loading of special CSS or javascript for other user groups.
:--[[User:Davidgothberg|David Göthberg]] ([[User talk:Davidgothberg|talk]]) 12:03, 6 January 2010 (UTC)
::{{tick|18}} '''{{ucfirst:Done}}''' - I have updated Common.js with the code above. Sysop.css is now loaded before page rendering.
::--[[User:Davidgothberg|David Göthberg]] ([[User talk:Davidgothberg|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]]:
<syntaxhighlight lang="javascript">
// 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");
}
</syntaxhighlight>
: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.
:--[[User:Davidgothberg|David Göthberg]] ([[User talk:Davidgothberg|talk]]) 22:41, 12 January 2010 (UTC)
::{{tick|18}} '''{{ucfirst:Done}}''' – --[[User:Davidgothberg|David Göthberg]] ([[User talk:Davidgothberg|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 {{tlc|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.
::--[[User:Davidgothberg|David Göthberg]] ([[User talk:Davidgothberg|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 {{tl|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:
:<code><span id="wikiminiatlas-load"></span></code>
And I will change the code in [[MediaWiki:Common.js]] that loads [[meta:MediaWiki:Wikiminiatlas.js]] to this:
<syntaxhighlight lang="javascript">
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")
} );
</syntaxhighlight>
I will notify the people who work with coordinates and Dschwen who seems to be the main coder of the WikiMiniAtlas system.
--[[User:Davidgothberg|David Göthberg]] ([[User talk:Davidgothberg|talk]]) 17:21, 15 January 2010 (UTC)
:Wikiminiatlas is currently active for every geolink {{tl|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. —[[User:TheDJ|Th<span style="color: green">e</span>DJ]] ([[User talk:TheDJ|talk]] • [[Special:Contributions/TheDJ|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. --[[User:Dschwen|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 {{tl|coor URL}}. It seems the trigger id should be added to that template instead.
::--[[User:Davidgothberg|David Göthberg]] ([[User talk:Davidgothberg|talk]]) 18:30, 15 January 2010 (UTC)
:::It's not "no problem", it's ''invalid HTML''. Both [http://www.w3.org/TR/html401/struct/global.html#adef-id HTML4] and [http://dev.w3.org/html5/spec/Overview.html#the-id-attribute 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 <samp>getElementById()</samp> rather than the more expensive <samp>getElementsByClassName()</samp>; 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. [[User:Happy-melon|<span style="color:forestgreen">'''Happy'''</span>]]‑[[User talk:Happy-melon|<span style="color:darkorange">'''melon'''</span>]] 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. —[[User:TheDJ|Th<span style="color: green">e</span>DJ]] ([[User talk:TheDJ|talk]] • [[Special:Contributions/TheDJ|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.
::--[[User:Davidgothberg|David Göthberg]] ([[User talk:Davidgothberg|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). —[[User:TheDJ|Th<span style="color: green">e</span>DJ]] ([[User talk:TheDJ|talk]] • [[Special:Contributions/TheDJ|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. —[[User:TheDJ|Th<span style="color: green">e</span>DJ]] ([[User talk:TheDJ|talk]] • [[Special:Contributions/TheDJ|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. [[User:Happy-melon|<span style="color:forestgreen">'''Happy'''</span>]]‑[[User talk:Happy-melon|<span style="color:darkorange">'''melon'''</span>]] 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.
:--[[User:Davidgothberg|David Göthberg]] ([[User talk:Davidgothberg|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. — [[User:Dispenser|Dispenser]] 19:17, 15 January 2010 (UTC)
{{hidden begin|title=WMA loader lite}}
<syntaxhighlight lang="javascript">
// 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(/¶ms=([^&=<>|]{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);
//</syntaxhighlight>
{{hidden end}}
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. — [[User:Dispenser|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. --[[User:Dschwen|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. — [[User:Dispenser|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. --[[User:Dschwen|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. —[[User:TheDJ|Th<span style="color: green">e</span>DJ]] ([[User talk:TheDJ|talk]] • [[Special:Contributions/TheDJ|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. --[[User:Dschwen|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. --[[User:Dschwen|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. —[[User:TheDJ|Th<span style="color: green">e</span>DJ]] ([[User talk:TheDJ|talk]] • [[Special:Contributions/TheDJ|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. —[[User:TheDJ|Th<span style="color: green">e</span>DJ]] ([[User talk:TheDJ|talk]] • [[Special:Contributions/TheDJ|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. <s>Will try your other suggestion about the DOM updates.</s> --[[User:Dschwen|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. --[[User:Dschwen|Dschwen]] 17:54, 19 January 2010 (UTC)
::::::::::I realize now that I was looking at the old version apparently. Current is much better. —[[User:TheDJ|Th<span style="color: green">e</span>DJ]] ([[User talk:TheDJ|talk]] • [[Special:Contributions/TheDJ|contribs]]) 19:27, 19 January 2010 (UTC)
| |||