MediaWiki talk:Common.js/Archive 2: Difference between revisions
Content deleted Content added
←Created page with ' == Main Page Hack == For the main page hack that removes stuff on the main page, why not just use the page title mentioned in the HTML header of every page? For ...' |
pre |
||
| (8 intermediate revisions by 6 users not shown) | |||
Line 1:
{{talkarchive}}
== Main Page Hack ==
Line 83 ⟶ 84:
fr.wikipedia.org uses a nice hack in [http://fr.wikipedia.org/wiki/MediaWiki:Monobook.js its monobook.js] to add a toolbar button which opens a little popup window to ask for table dimensions, and to insert the table as wikitext into the edit box. Try it out by [http://fr.wikipedia.org/w/index.php?title=Alamans&action=edit editing a page] and clicking the table button (first from the left). Should we copy this idea?--[[User:Eloquence|Eloquence]][[User:Eloquence/CP|*]] 14:14, 25 August 2006 (UTC)
:Well, if there is no objections to this, we should try it out. I do not see any harm in doing this as well. --<
::Actually much of the stuff here[http://en.wikipedia.org/w/index.php?title=User:MarkS/extraeditbuttons.js] would be very useful for basic editing too.'''[[User talk:Voice of All|<
:::I've implemented all of these.'''[[User talk:Voice of All|<
== Reference navbar ==
See [http://en.wikipedia.org/wiki/User:Voice_of_All/UsefulJS#Google_searching.2Fcommon_spelling_corrections.2Freference_scrollbars.2Fabreviate_.28Requires_Addtab.29]. Within these scripts there is also a simple script ("Reference divs") that makes the auto-generated references appear with a scrollbar so that they won't take up so much room. I'd like to add this here.'''[[User talk:Voice of All|<
== Default hide/show for NavFrame ==
(following up from [
:I coded up a replacement for the <code>createNavigationBarToggleButton</code> function at [[MediaWiki:Monobook.js]] which allows one to specify if the box should be open or closed by default. It can be found at [{{fullurl:User:CesarB/monobook.js|oldid=73420426}}] if you want to check the code. Once it's added to Monobook.js (replacing the function already there), using <code>NavFrameDefaultHide</code> instead of <code>NavFrame</code> will force the box to be hidden by default, and using <code>NavFrameDefaultShow</code> instead of <code>NavFrame</code> will force the box to be shown by default. I intend to add the code to Monobook.js in a few days if nobody complains. --[[User:CesarB|cesarb]] 16:59, 2 September 2006 (UTC)
Line 140 ⟶ 141:
== Helper function for user scripts ==
I would like this funtion to be included so it's easier for users to include user scripts.
<pre>
/*Takes the wikipage "page" and includes it's raw text as javascript.*/
Line 166 ⟶ 167:
}
</pre>
**Off course every one can include it in their own script, but it's more tedious, also most people are using code like the one gimmetrow showed, and that's non optimal in at least two ways. First it will need to be reparsed when written, it is much faster to include it directly in the DOM-tree, second, when using document.writeln, the output will be written to the end of the document, generating a non-compatible page (application/xhtml-xml will bail out on such code generally). <sub>→<
== New buttons in edit toolbar ==
Please revert the addition of a ton of extra buttons, if a user wants them they can add them themself but that is truely overkill, i also see no visible consensus asking users if they would like them. <small
:This was brought up here a month ago, without objection. For such a visually minor change, I don't see the problem with adding some small buttons to the toolbar (and it is not bleeding over or anything). The ''vast'' majority of people who edit this site do not even know how to just "add them" or that they need an account, and they don't know javascript either. Some of these buttons are badly needed (ie table, which fr. has). Though perhaps a few could be shaved off just for the sake of simplicity.'''[[User talk:Voice of All|<
::[[User:Digital_me|Digital_me]] plans to write a bit of disabling javascript, but I agree with perhaps cutting them down. It is a little mad, and the WYSIWYG will be here reasonably soon. —[[User:Xyrael|Xyrael]] / 19:30, 24 September 2006 (UTC)
::Well, I don't think most people would know that there was discussion here. I think that this is a pretty major change, and the discussion should be more publicized. I, for one, oppose them, as they are more unnessecary clutter to the already mostly unused edit toolbar.--<b><span style="font-family:Trebuchet MS;">[[User:Digitalme|digital_m]][[User:Digitalme/EA|<span style="color:green;">e</span>]]<sup>([[User_talk:Digitalme|Talk]]•[[Special:Contributions/Digitalme|Contribs]])</sup></span></b> 19:31, 24 September 2006 (UTC)
::I just trimmed down the options. That should make it better for low-res now.'''[[User talk:Voice of All|<
:::To disable the new buttons just add the following to your [[Special:Mypage/monobook.js|monobook.js]], save, and do a hard refresh (ctrl-F5).
:::<pre>mwCustomEditButtons = false;</pre>
:::--<b><span style="font-family:Trebuchet MS;">[[User:Digitalme|digital_m]][[User:Digitalme/EA|<span style="color:green;">e</span>]]<sup>([[User_talk:Digitalme|Talk]]•[[Special:Contributions/Digitalme|Contribs]])</sup></span></b> 19:40, 24 September 2006 (UTC)
:::The table button isn't such a bad idea. But the table code produced by the form popping up needs to be improved. I wouln't want to have newbies entering such ugly defaults for tables. Hey and the template call button wasn't that bad. Too bad it has already been removed again. --[[User:Ligulem|Ligulem]] 19:42, 24 September 2006 (UTC)
::::I suppose we need to keep these for more bread-and-butter kind of tedious tasks, so that had to go.'''[[User talk:Voice of All|<
:::: Theres a transclusion button underneath the edit box ;-) <small
:::::Argh. I forgot my [http://en.wikipedia.org/wiki/User:Ligulem/monobook.css]. Thanks :) --[[User:Ligulem|Ligulem]] 19:49, 24 September 2006 (UTC)
:::::The template button on the top of the edit window is better than the "Wiki-markup" section below the edit window. --[[User:Ligulem|Ligulem]] 19:56, 24 September 2006 (UTC)
Line 185 ⟶ 186:
:::::::Agree with that. But could be dangerous. I fear hordes of angry Wikipedians piling at VPT :). Removing things is always delicate... --[[User:Ligulem|Ligulem]] 20:07, 24 September 2006 (UTC)
::: Many of the buttons are redundant with the wiki markup section, and do we really need a javascript button just to add a ':' ? [[User_talk:Gimmetrow|''Gimmetrow'']] 19:46, 24 September 2006 (UTC)
::::The ":" thing is now removed.'''[[User talk:Voice of All|<
::::: I'd say it's useful for new editors. On the other hand coloured text (already removed), left-aligned and centered text are not. —''[[User:R._Koot|Ruud]]'' 20:00, 24 September 2006 (UTC)
:::::: The : tab is rarely useful to a new editor in article space. By the time an editor runs across a need, they will have seen it on talk pages. [[User_talk:Gimmetrow|''Gimmetrow'']] 20:03, 24 September 2006 (UTC)
Line 194 ⟶ 195:
*hem* The new JS-code looks a bit bad (I thought VoA knows JS). Look some comments from me [[http://en.wikipedia.org/wiki/User_talk:MarkS#Support#here]] (and my corresponding optimized code [[:de:User:Olliminatore/customToolbar.js|here]], you can also look at the talkpage). I've completly replaced the <code>function marque_tab()</code> for the table button (after all buttons be added) p.s. I've not read any discussion to this relation before, so you can hint me. --[[User:Olliminatore|Olliminatore]] 12:49, 28 September 2006 (UTC)
:I mainly copied these from MarkS and they seemed to be fine. If anything can be optimized, then I'd <nowiki>{{sofixit}}</nowiki>.'''[[User talk:Voice of All|<
:: I can't do that but you can look [[User_talk:MarkS/extraeditbuttons.js|my code]] . Other matter: I think the
== Table button ==
Line 223 ⟶ 224:
::''Cross post'': Hmm, odd. It was still showing up on my toolbar. After my edit I did a hard refresh and it went away - so unless my cache was two days old (possible) - your commenting might not have been enough. Anyway, no harm done. <span style="font-family: Verdana;">[[User:ed_g2s|ed g2s]] • [[User talk:ed_g2s|talk]]</span> 14:04, 29 September 2006 (UTC)
:::''Cross post'': :Yes, you '''did''' have had an outdated cache, as the button already went away thanks to my edit. I'm going to revert your edit, if you don't mind. We either disable that code on the top-most level (as I did it with my edit), or we remove that stuff completely. Keeping some brain dead code there serves not much purpose. --[[User:Ligulem|Ligulem]] 14:08, 29 September 2006 (UTC)
::First a simple IE detector need to be added. If a user is using IE, then the button should be disabled. As for table appearance, anyone is welcome to fix it with something that looks prettier.'''[[User talk:Voice of All|<
::: My mentioned version has that feature, for IE (Opera too) the button makes only table sample syntax (from MarkS). (p.s. I don't tested IE for window open, because this function also don't works with my expanded function method) --[[User:Olliminatore|Olliminatore]] 20:26, 30 September 2006 (UTC)
::::Ok I simplified the code, and it does not seem to crash IE either. The talble now uses the pretty and simple wikiclasses.'''[[User talk:Voice of All|<
::::: You forgot to remove <nowiki>''' ''' from TABLE CAPTION and |----- to |-</nowiki> --[[User:Olliminatore|Olliminatore]] 10:37, 1 October 2006 (UTC)
::::: It crashed my version of IE (IE 6) about 5 minutes ago. Someone who know how should ''definitely'' disable the button in IE until the problem is fixed. (It doesn't always crash IE, just sometimes; it's worked for me before, so testing it once in IE isn't enough to indicate the end of the problem.) [[User:147.188.147.47|147.188.147.47]]
Line 236 ⟶ 237:
== Archive ==
Just a note to all. I have archived some of the contents of this page. If anyone has any objects over this, please feel free to state your concerns. --<
== Page not found ==
Line 265 ⟶ 266:
==Toolbar extras==
The extra buttons in the toolbar, though useful, are causing serious lag in the edit page load time. I first tried adding these extra buttons (stolen from the Hebrew Wikipedia) several months back, and noticed the problem then, as did others. The problem still exists. Currently, for me at least, the toolbar takes 5+ seconds to load. — <small>[[User:Brian0918|<b><
:I've never had them take 5 seconds, odd.'''[[User talk:Voice of All|<
::Me neither. IIRC I noticed a very minor lag the first time they had to load (but far below 5 seconds). Since then, they are in the cache of my Firefox 1.5.0.7 (Windows XP) and everything loads immediately (I still have them right now even though they have been removed already by Brian0918, because I didn't force a cache update yet). --[[User:Ligulem|Ligulem]] 08:42, 11 October 2006 (UTC)
:::These should ''really'' be added back. The toolbar can be disabled via prefrences. Many other wikipedias, like RU and FR, already have such buttons. I don't see a need to remove a few very useful sitewide buttons due to one user having them take too long to load.'''[[User talk:Voice of All|<
:::: Does the loading of the toolbar prevent editing? If not I don't see a problem with it loading so slowly. Even the standard toolbar can take 2 or 3 seconds to load when I'm running BitTorrent in the background. —''[[User:R._Koot|Ruud]]'' 16:35, 15 October 2006 (UTC)
:::::No, it just loads in the background. Actually, the bar loads near instantly, its the images that take a while sometimes, but it does not hang the page or anything, they just appear one by one.'''[[User talk:Voice of All|<
:::Please restore the extra buttons. They were very helpful. I experienced no delay in the edit box opening, and did not notice any delay in the button graphics being rendered (but a 5-second delay in that, if there was one, would not delay my editing). [[User:Finell|Finell]] [[User_talk:Finell|(Talk)]] 07:22, 16 October 2006 (UTC)
::::I agree: Bring back the buttons! They are very useful, and the only delay present is caused by loading the images. [[User:Albany NY|Albany NY]] 13:22, 16 October 2006 (UTC)
Line 276 ⟶ 277:
There is a strong concensus, in this and another item on this Talk page, for restoring the additional edit toolbar buttons. Will it be done? [[User:Finell|Finell]] [[User_talk:Finell|(Talk)]] 20:57, 26 October 2006 (UTC)
:I'd like for someone to add them back soon.'''[[User talk:Voice of All|<
Not a fan. Makes finding the few useful buttons (sig and redirect) harder. But I appear to be in the minority, so how can I remove these from my monobook? Should the "mwCustomEditButtons = false;" thing still work? --[[User:Spangineer|Spangineer]]<sup>[[:wikisource:User:Spangineer|ws]]</sup> [[User talk:Spangineer|<small
: Seems to work, except that it doesn't remove the "make table" button. —''[[User:R._Koot|Ruud]]'' 23:22, 5 November 2006 (UTC)
== Firefox 2.0 ==
The access keys don't work in the newly released [[Firefox]] 2.0 :( [[User:555pt|'''555'''pt]] | <small>[[User talk:555pt|msg]] | [[:pt:User talk:555|msg on w:pt]]</small> 04:27, 24 October 2006 (UTC)
:Use the Shift key as well. --[[User:TheParanoidOne|TheParanoidOne]] 09:34, 24 October 2006 (UTC)
::Er... Shift? If I press Shift+P in a edit box I get the P, not the preview page o.0 [[User:555pt|'''555'''pt]] | <small>[[User talk:555pt|msg]] | [[:pt:User talk:555|msg on w:pt]]</small> 17:27, 24 October 2006 (UTC)
:::You missed the "as well" part. Normally your would type Alt+P but with FF2 you need to do Shit+Alt+P. --[[User:TheParanoidOne|TheParanoidOne]] 19:14, 24 October 2006 (UTC)
== Collapsible tables fix for IE ==
Please make this change so that collapsible tables will display correctly in Internet Explorer:
{|border='0' width='98%' cellpadding='0' cellspacing='4' class='diff'
|colspan="2" align="left"|'''Line 278:'''
|colspan="2" align="left"|'''Line 278:'''
|-
|
|class="diff-context"|var ButtonText = document.createTextNode( collapseCaption );
|
|class="diff-context"|var ButtonText = document.createTextNode( collapseCaption );
|-
|
|class="diff-context"|
|
|class="diff-context"|
|-
| -
|class="diff-deletedline"|Button.<span class="diffchange">setAttribute( "</span>style"<span class="diffchange">, "float: </span>right;" <span class="diffchange">)</span>;
| +
|class="diff-addedline"|Button.style<span class="diffchange">.styleFloat = </span>"right<span class="diffchange">"</span>;
|-
|
|
| +
|class="diff-addedline"|Button.style.cssFloat = "right";
|-
|
|class="diff-context"|ButtonLink.setAttribute( "id", "collapseButton" + tableIndex );
|
|class="diff-context"|ButtonLink.setAttribute( "id", "collapseButton" + tableIndex );
|-
|
|class="diff-context"|ButtonLink.setAttribute( "href", "javascript:collapseTable(" + tableIndex + ");" );
|
|class="diff-context"|ButtonLink.setAttribute( "href", "javascript:collapseTable(" + tableIndex + ");" );
|}
;Notes:
*'''Original code:''' Setting the style attribute works in Mozilla, but IE forgets it. The result was that the triangle appeared immediately to the left of the header text in IE.
*'''Patched code:''' Assigning the style as an attribute forces IE to remember that the element should be floated. Mozilla ignores "styleFloat" and will still display the triangle correctly; IE ignores "cssFloat" and will still display the triangle correctly.[http://www.howtocreate.co.uk/tutorials/javascript/domcss]
*I have tested this patch on a local, bleeding-edge copy of MediaWiki from SVN using IE6 and Ffx2: no browser recorded a javascript error.
*From my experience coding this and the above source, I believe that this patch will work on all browsers.
—Cheers, [[User:DavidHOzAu|DavidH]][[User talk:DavidHOzAu|Oz]][[Special:Contributions/User:DavidHOzAu|Au]] 05:58, 7 November 2006 (UTC)
: I "committed" your patch. —''[[User:R._Koot|Ruud]]'' 19:41, 7 November 2006 (UTC)
== pl.wiki edit summaries ==
What do people think of the pl.wiki's "auto edit summary" thing? (See [http://pl.wikipedia.org/w/index.php?title=Matematyka&action=edit] for example, and try clicking on one of the green boxes below the edit summary field.) Is it worth implementing here? It might encourage people to use edit summaries more, because it'll be very easy to add. It will probably also help newbies who aren't sure what to type in the edit field by giving examples. —<span style="font: small-caps 14px times; color: red;">[[User:Mets501|Mets501]] ([[User talk:Mets501|talk]])</span> 18:22, 7 November 2006 (UTC)
:We now have that to some extent, thanks to [[Wikipedia:Automatic edit summaries|Automatic edit summaries]], which was recently checked in. What the Polish Wikipedia's doing sounds neat, though. – [[User:Mxn|Minh Nguyễn]] <small>([[User talk:Mxn|talk]], [[Special:Contributions/Mxn|contribs]])</small> 08:06, 20 November 2006 (UTC)
== Initial letter is shown capitalized due to technical restrictions ==
frwiki has implemented a change where if you go to [[:fr:IPod]], their javascript hides the {{tl|lowercase}} warning, and just modifies the name at the top of the page to read correctly (and it fails gracefully because the original {{tl|lowercase}} is still shown if javascript is off). I'd like to get this working on enwiki. Many of [[:Category:Wrong title templates|the templates]] have been changed, and [[User:Interiot/js/RealTitle.js]] is working now, if included from an individual's monobook.js. I've brought up the possibility of including the change in the global monobook.js at [http://en.wikipedia.org/w/index.php?title=Wikipedia:Village%20pump%20%28technical%29&oldid=90662470#Name_technical_restrictions_workaround Wikipedia:Village pump (technical)#Name technical restrictions workaround]. --[[User:Interiot|Interiot]] 08:28, 16 November 2006 (UTC)
: I've implemented several proposed fixes brought up at the village pump and the various [[:Category:Wrong title templates]]. The code is now more complex, but I believe it does the Right Thing in almost every case. Its operation and downsides are detailed at [[User talk:Interiot/js/RealTitle.js]]. If a few more days pass without any issues brought up, I'd like to add it to the global monobook.js. --[[User:Interiot|Interiot]] 06:17, 21 November 2006 (UTC)
:: I added this to the common.js now. Now everyone should see that pages like [[mod_perl]], [[:Category:x86 microprocessors]], and [[User:rambot]] show up with lowercase and underscores as needed (turn off javascript in your browser to see how they were displayed before). Pages like [[Softimage XSI]] shouldn't have their main title changed, but should have the title at the very top of the browser (or in the tab) changed. --[[User:Interiot|Interiot]] 04:18, 24 November 2006 (UTC)
Do you know how much confusion this has caused? And I'm only talking about myself here; think about all the other people that may have been racking their brains out over this. This thing shouldn't be here without more discussion first; if capital letters aren't technically possible for whatever reason, we shouldn't be making adjustments to make article titles look correct. Did nobody think that four people don't speak for everybody that has an account on Wikipedia? I don't want this; I want to see the {{tl|lowercase}} tags in articles as they should appear. Either revert this change and start a new discussion where more people are likely to comment, or give me a way to make article titles look the way I want them to look. <sub>[[User:J Di|JD]]</sub><sup>[[User talk:J Di|talk]]</sup> 20:38, 29 November 2006 (UTC)
: You can disable this now by adding {{mono|1=<span style="background-color:#cfc">disableRealTitle = 1;</span>}} to your monobook.js. The idea behind hiding {{tl|lowercase}} is that the only reason they're included on articles is because the title displays incorrectly. Once the title displays correctly, the reader doesn't need to be bothered about the internal limitation on that page anymore... is that incorrect? (just to clarify: it still appears on articles that don't have a pasteable title, for instance [[Special:Whatlinkshere/Template:Pipe_in_title|<nowiki>{{pipe in title}}</nowiki>]]) As [[Wikipedia talk:Naming conventions (technical restrictions)#Summary of lower case first letter issue|this discussion]] notes, multiple wikis have taken up this feature before en.wikipedia.org did, and there were a group of people who wanted English Wikipedia to have it earlier. The feature was discussed in numerous places... [http://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_%28technical%29&oldid=89177667#Name_technical_restrictions_workaround] [http://en.wikipedia.org/wiki/Template_talk:Lowercase#Redrafting_title_with_a_JavaScript_trick] [http://en.wikipedia.org/wiki/Template_talk:Lowercase-user] but I'd be happy to discuss it [[WP:VPT]] or elsewhere again if you'd like.
: If it's an issue about making sure people are informed, we could update [[:Category:Wrong title templates|the relevant templates]] and/or their talk pages to note the details of how/where this works. --[[User:Interiot|Interiot]] 23:53, 29 November 2006 (UTC)
::Out of curiosity, why is the variable called diableRealTitle instead of disableRealTitle (with an s)?
::In my opinion, Interiot allowed for enough discussion before making the change. -- [[User:Jitse Niesen|Jitse Niesen]] ([[User talk:Jitse Niesen|talk]]) 00:25, 30 November 2006 (UTC)
::: Oops, thanks for noting that. It's been changed to the obviously more correct disableRealTitle. --[[User:Interiot|Interiot]] 00:57, 30 November 2006 (UTC)
:::: Nicely done, by the way, good work! Seems to work well, and the work's appreciated. [[User:Snoutwood|Snoutwood]] [[User talk:Snoutwood|(talk)]] 06:40, 30 November 2006 (UTC)
== Copying to [[MediaWiki:Common.js]] ==
According to [[Wikipedia:Wikipedia_Signpost/2006-11-20/Technology_report|the Signpost]], this page is now deprecated. All of this should be copied to [[MediaWiki:Common.js]], and all of the stuff that we still want to keep specific only to Monobook.js should be added using a skin test with the <code>skin</code> variable. —<span style="font: small-caps 14px times; color: red;">[[User:Mets501|Mets501]] ([[User talk:Mets501|talk]])</span> 21:19, 21 November 2006 (UTC)
: Looks like it's already working. (eg. [http://en.wikipedia.org/w/index.php?title=-&action=raw&smaxage=0&gen=js] mentions that it's pulling its data from both MediaWiki:Common.js and MediaWiki:Monobook.js). If there's no monobook.js-specific code here, can we just move this page there? --[[User:Interiot|Interiot]] 21:36, 21 November 2006 (UTC)
:: I've moved the page, but it doesn't seem to work. Also {{tl|interwiki-all}} seems to be expanded now, I believe it didn't do that before. —''[[User:R._Koot|Ruud]]'' 22:55, 21 November 2006 (UTC)
:::Does this mean that now we can use show/hide boxes and they will work for everyone using any skin? —<span style="font: small-caps 14px times; color: red;">[[User:Mets501|Mets501]] ([[User talk:Mets501|talk]])</span> 23:49, 21 November 2006 (UTC)
I'm not sure why [http://en.wikipedia.org/w/index.php?title=MediaWiki:Common.js&diff=89336551&oldid=89322157 the page was blanked] after being moved over? It seems like it should work better without the blanking. --[[User:Interiot|Interiot]] 00:02, 22 November 2006 (UTC)
: Copied (not moved) the JS back to [[MediaWiki:Monobook.js]] for now. If common.js suddenly does start working, the code might be included twice, perhaps with worse sideeffect than having no JS for a while. —''[[User:R._Koot|Ruud]]'' 00:05, 22 November 2006 (UTC)
:: [http://en.wikipedia.org/w/index.php?title=MediaWiki:Common.js&diff=89338040&oldid=89336551 This edit] shows up [http://en.wikipedia.org/w/index.php?title=-&action=raw&smaxage=0&gen=js] for me. I think it's working, but maybe needs some waiting time or an action=purge? --[[User:Interiot|Interiot]] 00:10, 22 November 2006 (UTC)
::: It now works here as well. —''[[User:R._Koot|Ruud]]'' 00:16, 22 November 2006 (UTC)
:::: Works here too. —<span style="font: small-caps 14px times; color: red;">[[User:Mets501|Mets501]] ([[User talk:Mets501|talk]])</span> 00:22, 22 November 2006 (UTC)
==NavigationBarShowDefault==
I'd suggest to change the max. before collapsing to 2, or even 3, rather than just on 1 (current NavigationBarShowDefault setting). -- User:Docu
:If this is what makes some templates with the show/hide thing in them automatically close, could you revert this please, or tell me how I could make templates that are showing automatically stay hidden? <sub>[[User:J Di|JD]]</sub><sup>[[User talk:J Di|talk]]</sup> 06:45, 1 December 2006 (UTC)
::[[Template:Dynamic navigation box with image]] has a parameter "STATE=" which collapses them by default. -- User:Docu
::: Some templates assume the collapse count is either 0 or 1. It's unfortunate, but raising it above 1 will break some behaviour somewhere. [[User_talk:Gimmetrow|''Gimmetrow'']] 02:23, 18 December 2006 (UTC)
== IE fix? ==
Exactly what does this do and why isn't it in /skins-1.5/common/IEFixes.js? —''[[User:R._Koot|Ruud]]'' 15:22, 26 November 2006 (UTC)
<pre>
if (window.showModalDialog && document.compatMode && document.compatMode == "CSS1Compat")
{
var oldWidth;
var docEl = document.documentElement;
function fixIEScroll()
{
if (!oldWidth || docEl.clientWidth > oldWidth)
doFixIEScroll();
else
setTimeout(doFixIEScroll, 1);
oldWidth = docEl.clientWidth;
}
function doFixIEScroll() {
docEl.style.overflowX = (docEl.scrollWidth - docEl.clientWidth < 4) ? "hidden" : "";
}
document.attachEvent("onreadystatechange", fixIEScroll);
attachEvent("onresize", fixIEScroll);
}
</pre>
== deprecating addLoadEvent ==
Should we remove adLoadEvent, as it only duplicates the functionality of addOnloadHook (defined in [http://en.wikipedia.org/skins-1.5/common/wikibits.js wikibits.js]). This will break the user scripts of a few dozen users. —''[[User:R._Koot|Ruud]]'' 15:51, 26 November 2006 (UTC)
:Maybe make it a thin wrapper around the latter at first, and add a comment about it being deprecated. Do the same [[MediaWiki:Standard.js|here]] and [[MediaWiki:Editmenu.js|here]], and fix the call [[MediaWiki:Charset.js|here]]. Then contact the [{{fullurl:Special:Search|ns2=1&search=addLoadEvent}} users still using it] and suggest they change their scripts, and wait a bit. Before finally removing it completely an admin can fix the remaining instances, but it's probably more polite to ask before poking around other people's user scripts. —[[User:Ilmari Karonen|Ilmari Karonen]] <small>([[User talk:Ilmari Karonen|talk]])</small> 17:42, 26 November 2006 (UTC)
==Floating boxes==
Why is there no floating box for 'Featured content' in the sidebar? --[[User:Eleassar|'''Eleassar''']] <sup>[[User talk:Eleassar|my talk]]</sup> 10:31, 28 November 2006 (UTC)
== "Technical restrictions" title fix ==
I've noticed two problem with this fix, both relating to when a page using it is edited. The first occurs when editing either the whole page or the "0" section. The correcting of the capitalisation occurs, but the "Editing " is not added to the beginning, nor it the "(section)" part for editing the "0" section. The second occurs when editing any other section in which no correction occurs but the "Editing " remains, effectively doing nothing at all.
Example for editing [[eBay]]:
{| class=wikitable
|-
!Editing:
!Intended result
!Actual result
|-
!Whole page
|Editing eBay
|eBay
|-
!Editing "0" section
|Editing eBay (section)
|eBay
|-
!Editing any other section
|Editing eBay (section)
|Editing EBay (section)
|}
'''[[User:Harryboyles|<i style="color:darkblue">Harryboyles</i>]]''' 11:13, 5 December 2006 (UTC)
: It doesn't happen if you're editing but not previewing the article. But anyway...
: What's the best thing to trigger off of, for the script to know it's in editing mode? Is {{mono|wgIsArticle}} appropriate? --[[User:Interiot|Interiot]] 11:17, 5 December 2006 (UTC)
::I suggest checking if document.___location contains {{mono|/wiki/}} or {{mono|/w/}} at the beginning of the path.
if (document.___location.indexOf(wgServer + wgScriptPath + "/") == 0) { // editing mode
...
} else { // browse mode
...
}
::Monobook emits {{mono|wgServer}} and {{mono|wgScriptPath}} as global javascript variables; I'm not sure if other skins do the same. It might be better to just hard-wire it to {{mono|http:}}{{mono|//en.wikipedia.org/w/}} in that case. --[[User:DavidHOzAu|DavidH]][[User talk:DavidHOzAu|Oz]][[Special:Contributions/User:DavidHOzAu|Au]] 03:35, 10 December 2006 (UTC)
:::That catches a lot more than editing (e.g., history, and even articles themselves if a URL like http://en.wikipedia.org/w/index.php?title=EBay is used). For history and diff pages, wgIsArticle is also set to false. If you want to catch only edit pages, perhaps check for "action=edit" and "action=submit" (the latter for previews) in the URL? -- [[User:Jitse Niesen|Jitse Niesen]] ([[User talk:Jitse Niesen|talk]]) 04:55, 10 December 2006 (UTC)
::::Ooops, I forgot about page actions. Ok then here's the full-blown code snippet:
if (document.___location.indexOf(wgServer + wgScriptPath + "/") == 0) {
var action_matches = document.___location.match( /action=([^&]+)/ );
var action = (action_matches == null) ? 'view' : action_matches[1];
switch(action) {
case 'history':
case 'print':
case 'purge':
case 'render':
case 'view':
isPreview = false;
break;
case 'submit':
isPreview = true;
break;
default: // nothing to do
return;
}
}
// rest of code here
::::Or something. --[[User:DavidHOzAu|DavidH]][[User talk:DavidHOzAu|Oz]][[Special:Contributions/User:DavidHOzAu|Au]] 01:23, 11 December 2006 (UTC)
:::::Right, it would be good to keep the code as simple as possible. Yes, {{mono|wgIsArticle}}'s value does vary a bit in history/diff/move/protect/delete, but it doesn't matter what its value is under those situations, because true or false, we can't display the RealTitle in those cases anyway. {{mono|wgIsArticle}}'s value really only matters when {{mono|RealTitleBanner}} is rendered on screen, which is: 1) when viewing an article, and 2) when editing an article, and its value is good in both cases. So {{mono|wgIsArticle}} should work fine, I think. --[[User:Interiot|Interiot]] 01:50, 11 December 2006 (UTC)
== NavFrame styles limitation ==
As it stands right now, NavFrame limits the use of class tags on elements to ONLY the <code>Nav*</code> classes. You cannot do something like <code>class="NavFrame messagebox standard-talk"</code>. This is because of the following lines:
if (NavChild.className == 'NavPic') {
...
if (NavChild.className == 'NavContent') {
...
if (NavChild.className == 'NavPic') {
...
if (NavChild.className == 'NavContent') {
...
if (NavFrame.className == "NavFrame") {
...
if (NavFrame.childNodes[j].className == "NavHead") {
Each of these should be changed to [[regular expression]] matches, respectively:
if (NavChild.className.match(/(\s|^)NavPic(\s|$)/)) {
...
if (NavChild.className.match(/(\s|^)NavContent(\s|$)/)) {
...
if (NavChild.className.match(/(\s|^)NavPic(\s|$)/)) {
...
if (NavChild.className.match(/(\s|^)NavContent(\s|$)/)) {
...
if (NavFrame.className.match(/(\s|^)NavFrame(\s|$)/)) {
...
if (NavFrame.childNodes[j].className.match(/(\s|^)NavHead(\s|$)/)) {
This will allow us to apply other classes to NavFrame and related elements. [[User:SG|♠ SG]] [[User talk:SG|→Talk]] 20:11, 25 December 2006 (UTC)
*Also, after looking into it further, there seem to be some inconsistencies in the file. Some parts use <code>function hasClass</code>, which is horribly inefficient:
function hasClass( element, className ) {
var Classes = element.className.split( " " );
for ( var i = 0; i < Classes.length; i++ ) {
if ( Classes[i] == className ) {
return ( true );
}
}
return ( false );
}
It could easily be rewritten as:
function hasClass(element, className) {
return element.className.match((new RegExp("(\\s|^)"+className+"(\\s|$)")));
}
After making that change, the previous rewrites I mentioned (such as <code>if (NavChild.className.match(/(\s|^)NavPic(\s|$)/)) {</code>) should be reformed (ie. <code>if (hasClass(NavChild, 'NavPic')) {</code>). [[User:SG|♠ SG]] [[User talk:SG|→Talk]] 20:43, 25 December 2006 (UTC)
: I've modified the collapsible tables to use literal regular expressions (which are faster than dynamically created RegExp-obejcts [http://developer.mozilla.org/en/docs/Core_JavaScript_1.5_Guide:Regular_Expressions]). I'm having trouble changing NavFrame, though. —''[[User:R._Koot|Ruud]]'' 23:47, 25 December 2006 (UTC)
:It's not "horribly inefficient". There are seldom more than 3 spaces in the "class" attribute. Unless you have a performance test showing that there's a problem, this is a [[premature optimization]]. [[User talk:Mike Dillon|Mike Dillon]] 16:26, 26 December 2006 (UTC)
::If we are going to premative optimize a bit more, I would change (foo) to (?:foo) to ansure we cont capture it. <sub>→[[User:AzaToth|<span style="color:#773">Aza</span>]][[User_talk:AzaToth|<span style="color:#359">Toth</span>]]</sub> 16:43, 26 December 2006 (UTC)
I just ran this test (sorry for the size):
: ''See code at [[User:Mike Dillon/NavFrame test]]''
The results were pretty consistently something like:
* hasClass1() x 10000: 532 ms
* hasClass2() x 10000: 818 ms
* hasClass3() x 10000: 765 ms
* hasClass4() x 10000: 523 ms
So, the regex version is fastest, but only if you can avoid recompiling it every time. I didn't see a consistent difference between hasClass2 and hasClass3, but hasClass1/4 were always about 30% faster than the others. Feel free to rerun this stuff yourself. The differences between the versions are:
* hasClass1: Compiles regex, uses reCache to avoid recompiling
* hasClass2: Compiles regex every time
* hasClass3: Uses split on space and equality check
* hasClass4: Compiles regex, uses reCache, avoids an extra function call for regex cache lookup
Another possible version would use indexOf, but I don't think it's worth writing it. Since the number of iterations of this thing will almost certainly be 2 orders of magnitude less than 10000, I can't see this stuff making a huge difference to load time. My feeling is that "hasClass" should remain a function, for convenience, and it should be implemented in the most readable way. [[User talk:Mike Dillon|Mike Dillon]] 17:16, 26 December 2006 (UTC)
P.S. I just tested the capture v. no capture versions by adding hasClass5:
<pre>
function hasClass5 (element, className) {
return element.className.match(
new RegExp("(\\s|^)\\Q" + className + "\\E(\\s|$)"));
}
</pre>
It made no consistent difference. It was a tiny bit faster to avoid the capture, but once again, the scale of this thing makes it moot. That doesn't mean that we shouldn't use the fastest one, it just means it doesn't make a significant difference. [[User talk:Mike Dillon|Mike Dillon]] 17:20, 26 December 2006 (UTC)
Just for kicks, I decided to reimplement part of Perl's Benchmark.pm in Javascript:
: ''See code at [[User:Mike Dillon/NavFrame test]] or [[User:Mike Dillon/Scripts/bench.js]]''
Here were the results for running the tests shown above:
* hasClass1() x 10000: 546 ms
* hasClass2() x 10000: 737 ms
* hasClass3() x 10000: 750 ms
* hasClass4() x 10000: 529 ms
* hasClass5() x 10000: 737 ms
<table border="1">
<tr><td> <th>Rate<th>hasClass3<th>hasClass2<th>hasClass5<th>hasClass1<th>hasClass4
<tr><th>hasClass3<td>13333/s<td>--<td>-1.8%<td>-1.8%<td>-37.4%<td>-41.8%
<tr><th>hasClass2<td>13569/s<td>+1.7%<td>--<td>0%<td>-35%<td>-39.3%
<tr><th>hasClass5<td>13569/s<td>+1.7%<td>0%<td>--<td>-35%<td>-39.3%
<tr><th>hasClass1<td>18315/s<td>+27.2%<td>+25.9%<td>+25.9%<td>--<td>-3.2%
<tr><th>hasClass4<td>18904/s<td>+29.5%<td>+28.2%<td>+28.2%<td>+3.1%<td>--
</table>
-- [[User talk:Mike Dillon|Mike Dillon]] 18:07, 26 December 2006 (UTC)
I added the literal regex test as well:
<pre>
compareAll(10000, {
"re+cache": function () { hasClass1(test, "a") },
"re+nocache": function () { hasClass2(test, "a") },
"split": function () { hasClass3(test, "a") },
"re+cache+onefunc": function () { hasClass4(test, "a") },
"re+nocache+capture": function () { hasClass5(test, "a") },
"re+literal": function () { test.className.match(/(?:^|\s)a(?:$|\s)/) },
});
</pre>
It is indeed the fastest, coming in at about 10-15% faster than the one-function caching version (hasClass4). However, like I said before, I think the value of having this as a function outweighs the value of having the fastest implementation, given that the order of magnitude is much lower than 10000. [[User talk:Mike Dillon|Mike Dillon]] 18:47, 26 December 2006 (UTC)
I've posted all of this code together at [[User:Mike Dillon/NavFrame test]]. [[User talk:Mike Dillon|Mike Dillon]] 18:49, 26 December 2006 (UTC)
: Cool! (Even though the outcome doesn't really surprise me.) I initially planned to comment on the "horrible inefficiency" of my <code>hasClass</code> function, but then decided I did like the elegance of regular expressions in JavaScript. —''[[User:R._Koot|Ruud]]'' 20:11, 26 December 2006 (UTC)
:: What do you think about using a version of "hasClass" with the regex caching? [[User talk:Mike Dillon|Mike Dillon]] 20:23, 26 December 2006 (UTC)
:At the risk of sounding like I'm talking to myself... I've removed the previous code samples out of this discussion. You can see them at [[User:Mike Dillon/NavFrame test]]. The summary is that the testing results consistently show the following performance order:
:# Constant regex (Ruud's version)
:# hasClass() implemented with regex cache (my version, a.k.a. hasClass4)
:# hasClass() implemented with split (old version, a.k.a. hasClass3)
:# hasClass() implemented with regex and no cache (SG's version, a.k.a. hasClass2)
:There was a little variance in whether the split or uncached regex version were faster, but in most of my test runs the split version was faster than SG's version (one of the results shown above was an exception to this). I'm obviously partial to my version, because it is fast enough compared to the constant regex version and allows the function to be reused. [[User talk:Mike Dillon|Mike Dillon]] 20:21, 26 December 2006 (UTC)
::Since this stuff is obviously browser specific, I tested this again in Firefox 2.0 (I was using [[Galeon]]/Mozilla 1.7). In Firefox, the split version is consistently the slowest. The caching versions are always faster than the non-caching versions and the constant regex is always fastest. [[User talk:Mike Dillon|Mike Dillon]] 20:28, 26 December 2006 (UTC)
:::This is way cool! Good jobs! --[[User:Chochopk|ChoChoPK]] (球球PK) ([[User talk:Chochopk|talk]] | [[Special:Contributions/Chochopk|contrib]]) 05:03, 27 December 2006 (UTC)
::::Thanks! After a discussion on [[User:R. Koot|Ruud]]'s talk page, I'm pretty sure I figured out the problem he was having with the regex matching code for the NavFrame structures. I believe the issue was that the code was calling ".className.match()" on all the child nodes of the NavFrame and some of them were text nodes, not elements (which means they don't have ".className"). For me, this is yet another reason to retain the hasClass() function instead of using constant regexes. [[User talk:Mike Dillon|Mike Dillon]] 16:05, 27 December 2006 (UTC)
===Long response===
Ah, great tests! I believe I did exaggerate in saying that the function is slow, so I apologize for that. Good move with the cache idea and <code>?:</code>; your function is quite superior to mine.
====Failure====
'''However''', actually testing the result of your regular expression ALWAYS returns false/null. This is due to using quote: <code>\Q...\E</code>. As far as I know, JavaScript regexp does not support this. That's alright, though, because valid classNames never contain any metacharacters (except -, which is useless without []).
====Optimized optimization====
I ran some tests of my own, and optimized your function. I created four variations, but only one of them turned out faster than yours:
<pre>var hasClass9 = (function () {
var reCache = {};
return function (element, className) {
return (reCache[className] ? reCache[className] : (reCache[className] = new RegExp("(?:\\s|^)" + className + "(?:\\s|$)"))).test(element.className);
};
})();</pre>
Now, on average, Internet Explorer 6/7 and Firefox 2.0 show no difference whatsoever between my function and yours, so I'll just show one of IE7's results, while skipping a few of the slow ones (note: in Firefox, I had to test each function one at a time; it seems Firefox executes scripts slower as they progress, I assume this is a memory issue as Firefox has always had):
'''Edit:''' These Internet Explorer 7 results are from before I removed <code>\\Q...\\E</code>. Strangely enough, after cleaning that out, Internet Explorer started running onefunc9 faster than onefunc4. Weird!
#re+cache x 10000: 441 ms
#split x 10000: 611 ms
#re+literal x 10000: 420 ms
#re+cache+onefunc4 x 10000: 351 ms
#re+cache+onefunc9 x 10000: 351 ms
<table border="1">
<tr><td> Internet Explorer 7</td><th>Rate</th><th>split</th><th>re+cache</th><th>re+literal</th><th>re+cache+onefunc4</th><th>re+cache+onefunc9</th></tr>
<tr><td>split</td><td>16367/s</td><td>--</td><td>-38.5%</td><td>-45.5%</td><td>-74.1%</td><td>-74.1%</td></tr>
<tr><td>re+cache</td><td>22676/s</td><td>+27.8%</td><td>--</td><td>-5%</td><td>-25.6%</td><td>-25.6%</td></tr>
<tr><td>re+literal</td><td>23810/s</td><td>+31.3%</td><td>+4.8%</td><td>--</td><td>-19.7%</td><td>-19.7%</td></tr>
<tr style="background-color:#eef"><td>re+cache+onefunc4</td><td>28490/s</td><td>+42.6%</td><td>+20.4%</td><td>+16.4%</td><td>--</td><td>0%</td></tr>
<tr style="background-color:#efe"><td>re+cache+onefunc9</td><td>28490/s</td><td>+42.6%</td><td>+20.4%</td><td>+16.4%</td><td>0%</td><td>--</td></tr>
</table>
Ah, but then I tested it on Safari and Opera -- and trust me, I'm as surprised as you:
#re+cache x 10000: 403 ms
#split x 10000: 494 ms
#re+literal x 10000: 411 ms
#re+cache+onefunc4 x 10000: 362 ms
#re+cache+onefunc9 x 10000: 277 ms
<table border="1">
<tr><td> Safari</td><th>Rate</th><th>split</th><th>re+cache</th><th>re+literal</th><th>re+cache+onefunc4</th><th>re+cache+onefunc9</th></tr>
<tr><td>split</td><td>20243/s</td><td>--</td><td>-20.2%</td><td>-22.6%</td><td>-36.5%</td><td>-78.3%</td></tr>
<tr><td>re+cache</td><td>24331/s</td><td>+16.8%</td><td>--</td><td>-2%</td><td>-13.5%</td><td>-48.4%</td></tr>
<tr><td>re+literal</td><td>24814/s</td><td>+18.4%</td><td>+1.9%</td><td>--</td><td>-11.3%</td><td>-45.5%</td></tr>
<tr style="background-color:#eef"><td>re+cache+onefunc4</td><td>27624/s</td><td>+26.7%</td><td>+11.9%</td><td>+10.2%</td><td>--</td><td>30.7%</td></tr>
<tr style="background-color:#efe"><td>re+cache+onefunc9</td><td>36101/s</td><td>+43.9%</td><td>+32.6%</td><td>+31.3%</td><td>23.5%</td><td>--</td></tr>
</table>
Opera is even crazier, look at how fast it does the split function:
#re+cache x 10000: 260 ms
#split x 10000: 190 ms
#re+literal x 10000: 231 ms
#re+cache+onefunc4 x 10000: 240 ms
#re+cache+onefunc9 x 10000: 150 ms
<table border="1">
<tr><td> Opera 9</td><th>Rate</th><th>re+cache</th><th>re+cache+onefunc4</th><th>re+literal</th><th>split</th><th>re+cache+onefunc9</th></tr>
<tr><td>re+cache</td><td>38462/s</td><td>--</td><td>-8.3%</td><td>-12.6%</td><td>-36.8%</td><td>-73.3%</td></tr>
<tr style="background-color:#eef"><td>re+cache+onefunc4</td><td>41667/s</td><td>+7.7%</td><td>--</td><td>-3.9%</td><td>-26.3%</td><td>-60%</td></tr>
<tr><td>re+literal</td><td>43290/s</td><td>+11.2%</td><td>+3.8%</td><td>--</td><td>-21.6%</td><td>-54%</td></tr>
<tr><td>split</td><td>52632/s</td><td>+26.9%</td><td>+20.8%</td><td>+17.7%</td><td>--</td><td>+26.7%</td></tr>
<tr style="background-color:#efe"><td>re+cache+onefunc9</td><td>66667/s</td><td>+42.3%</td><td>+37.5%</td><td>+35.1%</td><td>-21.1%</td><td>--</td></tr>
</table>
====Better testing====
Regardless, this is a highly unrealistic test case. More often than not, we will only be looking for a specific class a few times per page (on a busy talk page, with a few project headers, let's say 1-4). To simulate this, we'll pick a random character each time the function is called (still unrealistic, as we won't be doing 10000 of these with 27 choices). So, instead of searching for "d": <code>String.fromCharCode(97 + Math.round(Math.random() * 25)</code>.
With this test in Opera, re+cache+onefunc9 wins every time by 30-40%. re+cache+onefunc4, split and re+cache seem to vary, randomly trading places on each try. re+nocache and re+nocache+capture are a whopping 260% slower than onefunc9.
Firefox shows me that re+cache+onefunc9 bests re+cache+onefunc4 again, but only by about 5-20%. Like Opera, the nocache functions are the slowest, by about 120%.
Internet Explorer is faster than Firefox overall, except that split is the slowest, at around -80%.
Safari showed results similar to Internet Explorer, except split was at -115%.
Whew, sorry for this long comment, but JavaScript is fun! [[User:SG|♠ SG]] [[User talk:SG|→Talk]] 01:18, 28 December 2006 (UTC)
:By the way, [[User:SG/NavFrame test]]. [[User:SG|♠ SG]] [[User talk:SG|→Talk]] 01:21, 28 December 2006 (UTC)
:Thanks for the catch on \Q...\E. I obviously didn't to any functional testing, just performance testing ;) You're right that the lack of quoting shouldn't be a problem in practice, since valid CSS class names can't contain any metacharacters. I was just being paranoid. Thanks also for the extra testing. So correct me if I'm wrong, but the difference between hasClass4 and hasClass9 is that hasClass9 substitutes an extra array access for an assignment? I reran the same tests on Linux and the no-assign version is faster there too, so I guess we have a winner. [[User talk:Mike Dillon|Mike Dillon]] 01:54, 28 December 2006 (UTC)
::Yes, it seems pretty weird. It's just that the JavaScript implementations vary widely from browser to browser. Oh, one other thing. In response to the error that occurs when trying to <code>.className.match()</code> on an element which doesn't have className (such as a text node, though you shouldn't be doing that in the first place), a simple <code>if (element.className)</code> could be added, and that prevents the browser from trying to do a match. [[User:SG|♠ SG]] [[User talk:SG|→Talk]] 02:13, 28 December 2006 (UTC)
:::Exactly what I was thinking. I think the value of being able to blindly call hasClass() on everything in .childNodes makes it worth having the .className check in the function.
:::However, I just realized that another way to avoid this is using RegExp.test(String) instead of String.match(RegExp), just as you did in hasClass9(). I pretty sure that calling test with a null argument isn't ever a problem. That way the extra "if" test isn't done in cases where it isn't needed; the miniscule performance hit only happens if you lazily pass a non-Element node to hasClass(). I'd appreciate it if you could test RegExp.test(null) on the browsers you have access to, but I assume it shouldn't be a problem on any of them. [[User talk:Mike Dillon|Mike Dillon]] 02:22, 28 December 2006 (UTC)
::::You are right. I tested it on IE6/7, FF2, Opera 9 and Safari; none of them report an error. So, I guess we won't be needing that if statement after all. We won't need to accommodate non-elements though, as that would be the fault of the coder, not the function. [[User:SG|♠ SG]] [[User talk:SG|→Talk]] 02:40, 28 December 2006 (UTC)
:::::If you mean non-Nodes, I agree. But I think any DOM node, including Text nodes should be testable with this function, for the sake of convenience. Limiting to Element limits usefulness. [[User talk:Mike Dillon|Mike Dillon]] 02:43, 28 December 2006 (UTC)
::::::Yes, sorry, non-nodes. It'll work on anything that exists (it'll only throw an error if you try to access element.attribute if element does not exist). Oh, I forgot to mention that this also works on IE5.5, but IE5 fails (for other reasons; .test(null) actually works). [[User:SG|♠ SG]] [[User talk:SG|→Talk]] 02:47, 28 December 2006 (UTC)
:::::::I hate to ask, but what failed in IE5? I'm pretty sure IE5 is almost negligible these days, but I couldn't find current browser stats for English Wikipedia. [[Wikipedia:Browsers]] still had about 16% IE5 in October 2004...
:::::::P.S. It looks like you have a faster computer than me :) Mine's a Pentium 4 2.6 GHz running Linux (Fedora Core 5). [[User talk:Mike Dillon|Mike Dillon]] 03:08, 28 December 2006 (UTC)
::::::::Well, IE5 doesn't support <code>?:</code>. It really doesn't conform to the regex specs. It also doesn't have array.push, which is used in your test function (but that is easily fixed). It's pointless to support IE5 anymore; approximately 1% of the world's browser usage is IE5.x, of which the majority is 5.5. With IE7 out and already gaining share, there is no reason to even test with IE5 anymore, due to the workarounds required. Wikipedia doesn't render properly in IE5 anyways, and there are plenty of script errors.
::::::::Just by guessing, I'd say Wikipedia's IE5.x usage is at 1-3%. Back in October 2004, the world IE5.x share was approximately 12%. Really, that 1-3% is not worth putting in time and effort to make scripts less efficient. They can still access the site, it just renders improperly and most scripts don't work.
::::::::As for my computer, well, I'm using a Pentium 4-M 2.2GHz on Windows XP (actually, TinyXP). I'm guessing I have a faster hard drive and/or RAM, seeing as how your CPU is obviously superior to mine. [[User:SG|♠ SG]] [[User talk:SG|→Talk]] 04:12, 28 December 2006 (UTC)
== hasClass doesn't work with NavFrame ==
I get the error <code>element has no properties</code> when viewing [[User:R. Koot/Sandbox|my sandbox]], after which the page is blanked. —''[[User:R._Koot|Ruud]]'' 16:25, 28 December 2006 (UTC)
:I'm not getting an error... I guess we could put an <code>if (!element) { return false }</code> inside the inner function of hasClass() just to be safe. It's weird that you're getting that error and I'm not. [[User talk:Mike Dillon|Mike Dillon]] 16:42, 28 December 2006 (UTC)
:Also, what browser are you testing and where does the page blank? That might give some indication of where the problem is. [[User talk:Mike Dillon|Mike Dillon]] 16:44, 28 December 2006 (UTC)
:: FF 2.0.0.1. I've added a test for a non-existant element, but now NavFrame is broken? (The show/hide button doesn't appear.) —''[[User:R._Koot|Ruud]]'' 17:30, 28 December 2006 (UTC)
:::I assume this is fixed, am I correct? I don't see an additional if statement and all of the collapsible elements seem to be working in your sandbox. [[User:SG|♠ SG]] [[User talk:SG|→Talk]] 19:07, 28 December 2006 (UTC)
:::: Yes, it's fix now [http://en.wikipedia.org/w/index.php?title=MediaWiki%3ACommon.js&diff=96962371&oldid=96948338]. —''[[User:R._Koot|Ruud]]'' 20:25, 28 December 2006 (UTC)
It appears that there was an attempt to assimilate NavFrame with collapsible by this line
var NavigationBarShowDefault = autoCollapse;
where it was previously initialized as 3. The old behavior was 4 or more of NavFrame boxes will be collapsed. So should the line read
var NavigationBarShowDefault = autoCollapse - 1;
?? --[[User:Chochopk|ChoChoPK]] (球球PK) ([[User talk:Chochopk|talk]] | [[Special:Contributions/Chochopk|contrib]]) 02:33, 29 December 2006 (UTC)
: Not according to the comment in the code just above that line, I'll look into it. —''[[User:R._Koot|Ruud]]'' 13:24, 29 December 2006 (UTC)
== Too many calls to document.getElementsByTagName() ==
Since we're on the topic of optimizing Common.js, I looked through all the code and noticed that there are three places that are calling document.getElementsByTagName() on every iteration of a for loop. In these cases, that function should only be called once, before the for loop. I've made a personal copy of Common.js at [[User:Mike Dillon/MediaWiki:Common.js]] that shows the changes in the most recent diff. [[User talk:Mike Dillon|Mike Dillon]] 18:57, 28 December 2006 (UTC)
:Actually, it's faster to only search for getElementsByTagName at each iteration. Why? Because if you do this:
var all = elem.getElementsByTagName('li'); for (...) { ... }
...every time ANY element contained in <code>all</code> is changed even slightly, the entire array has to be updated again. By accessing getElementsByTagName on each iteration, we only update one variable. Here's a good reference:[http://www.peachpit.com/articles/article.asp?p=31567&seqNum=5&rl=1]
{{Quotation|In most cases, this is faster than caching the NodeList. In the second example, the browser doesn't need to create the node list object. It needs only to find the element at index i at that exact moment.}}
However, there are some cases where optimization is due, such as:
for(var j=0; b = document.getElementsByTagName("li")[j]; j++) {
This here, in <code>function LinkFA</code>, is actually searching the entire document for list elements. It should actually only be looking for them in the 'p-lang' element:
document.getElementById('p-lang').getElementsByTagName("li")[j]
Except here, I'm not sure whether or not it's faster to cache p-lang or to look it up every time. Time for more execution speed tests? [[User:SG|♠ SG]] [[User talk:SG|→Talk]] 19:32, 28 December 2006 (UTC)
:: I'm not sure what you're saying here. From what I can see, <code>document.getElementsByTagName("div")[i]</code> searches for all divs and then indexes into the resulting HTMLCollection on each pass. I don't think you can assume that it would optimize that into "look for the i-th <code>div</code>" on each pass. Is that what you're saying? This isn't a caching thing. It's avoiding repeatedly collecting the divs. The HTMLCollection contains a bunch of pointers to nodes, so I don't see what updating the nodes themselves has to do with that. All of the cases I changed are cases of calling getElementsByTagName() on Document, not on an individual element. [[User talk:Mike Dillon|Mike Dillon]] 20:46, 28 December 2006 (UTC)
: I'm already busy rewriting LinkFA() (which requires a change to {{tl|Link FA}} as well.) —''[[User:R._Koot|Ruud]]'' 20:27, 28 December 2006 (UTC)
:: I'm getting a "missing name after <code>.</code> operator". I think you need to use ".className" instead of ".class" in the code <code>if ( document.getElementById( InterwikiLinks[i].class + "-fa" ) ) {</code>. [[User talk:Mike Dillon|Mike Dillon]] 20:52, 28 December 2006 (UTC)
::: Indeed, I hate not being able to use Eclipse ;) —''[[User:R._Koot|Ruud]]'' 21:12, 28 December 2006 (UTC)
I just did this quick test in a document with 100 empty divs:
<pre>
compareAll(1000, {
"fetch-many": function () {
var d;
for (var i = 0; d = document.getElementsByTagName("div")[i]; i++) {
}
},
"fetch-once": function () {
var d;
var divs = document.getElementsByTagName("div");
for (var i = 0; d = divs[i]; i++) {
}
},
});
</pre>
The results were:
* fetch-many x 1000: 4702 ms
* fetch-once x 1000: 1305 ms
The result had pretty much the same time profiles in Galeon and Firefox on Linux. Maybe the results will be different in another browser, but I doubt it. [[User talk:Mike Dillon|Mike Dillon]] 21:20, 28 December 2006 (UTC)
:I just tested with 10 divs and "fetch-once" is still faster:
<pre>
var body = document.getElementsByTagName("body")[0];
var div = document.createElement("div");
for (var i = 0; i < 10; i++) {
body.appendChild(div.cloneNode(false));
}
compareAll(1000, {
"fetch-many": function () {
var d;
for (var i = 0; d = document.getElementsByTagName("div")[i]; i++) {
}
},
"fetch-once": function () {
var d;
var divs = document.getElementsByTagName("div");
for (var i = 0; d = divs[i]; i++) {
}
},
});
</pre>
:I don't think that the Peachpit article is right. [[User talk:Mike Dillon|Mike Dillon]] 21:24, 28 December 2006 (UTC)
::The article seems to be assuming that you're manipulating the DOM tree within the loop, such that the content of the NodeList object returned by getElementsByTagName() gets updated deveral times. In that case the method recommended in the article ''might'' be faster. In any case, I suspect that an even better solution for such cases would be to copy the content of the NodeList into an ordinary array before the actual DOM-manipulation loop. —[[User:Ilmari Karonen|Ilmari Karonen]] <small>([[User talk:Ilmari Karonen|talk]])</small> 22:30, 28 December 2006 (UTC)
:::Go ahead and test it. I'm not sure you're right, since you have to iterate through the whole HTMLCollection followed by the array if you do that, but maybe there's some bookkeeping overhead of iterating through the HTMLCollection while unrelated changes are happening in the DOM. My tests weren't doing any DOM manipulation, so maybe that makes a difference. [[User talk:Mike Dillon|Mike Dillon]] 22:34, 28 December 2006 (UTC)
This was easy enough to test, so I did it:
<pre>
var body = document.getElementsByTagName("body")[0];
var div = document.createElement("div");
for (var i = 0; i < 10; i++) {
body.appendChild(div.cloneNode(false));
}
var span = document.createElement("div");
compareAll(1000, {
"fetch-many": function () {
var d;
for (var i = 0; d = document.getElementsByTagName("div")[i]; i++) {
var copy = span.cloneNode(false);
d.appendChild(copy);
d.removeChild(copy);
}
},
"fetch-once": function () {
var d;
var divs = document.getElementsByTagName("div");
for (var i = 0; d = divs[i]; i++) {
var copy = span.cloneNode(false);
d.appendChild(copy);
d.removeChild(copy);
}
},
"fetch-copy": function () {
var d;
var divs = document.getElementsByTagName("div");
var divsCopy = new Array();
for (var i = 0; d = divs[i]; i++) {
divsCopy.push(d);
}
for (var i = 0; d = divsCopy[i]; i++) {
var copy = span.cloneNode(false);
d.appendChild(copy);
d.removeChild(copy);
}
},
});
</pre>
The order was:
# fetch-many (slowest)
# fetch-once
# fetch-copy (fastest)
So, the PeachPit article may be right if there are DOM changes happening, which there are in the NavFrame case. [[User talk:Mike Dillon|Mike Dillon]] 22:38, 28 December 2006 (UTC)
:Well I'll be damned. I ran some tests of my own; mine modified className instead of the whole DOM tree, I figured it would be more realistic, as that's usually what we do on WP.
# fetch-many x 1000: 3245 ms
# fetch-copy x 1000: 2113 ms
# fetch-once x 1000: 1813 ms
Turns out once is a bit faster, with many being the slowest by far. So your original plan to do
var d;
var divs = document.getElementsByTagName("div");
for (var i = 0; d = divs[i]; i++) { ... }
was right on the money. [[User:SG|♠ SG]] [[User talk:SG|→Talk]] 03:09, 29 December 2006 (UTC)
:So it seems the conclusion is:
:*Don't call getElementsByTagName() repeatedly.
:*If you need to modify the DOM tree (not just attributes) while looping over the list, make a copy first.
:—[[User:Ilmari Karonen|Ilmari Karonen]] <small>([[User talk:Ilmari Karonen|talk]])</small> 06:30, 29 December 2006 (UTC)
::I don't know if my tests were totally representative, but I only saw a 5-15% difference when making the copy, so I'd say the copy may be a micro-optimization for the use cases represented in Common.js. We should keep in mind that the copy is a way to optimize code that does heavy DOM manipulation in a loop, but I don't think the extra complexity is warranted except to fix a known performance problem. [[User talk:Mike Dillon|Mike Dillon]] 06:37, 29 December 2006 (UTC)
::Maybe it's time to start [[Wikipedia:Javascript]] as a more long-term place to put performance hints for writing site-wide and personal Javascript. It would be a good place to highlight comparative testing strategies and caveats as well, along with pointers to things like the PeachPit article. [[User talk:Mike Dillon|Mike Dillon]] 06:40, 29 December 2006 (UTC)
:::I have to agree; while copying the nodes is faster, we probably won't be doing it 1000 times per page, so the difference is negligible. For the sake of simplicity, I say we should just list the elements once.
:::As for a WP:JS project, yes, that does sound like a good idea. Instead of just archiving all of these benchmarks, we could copy the important parts (ie. the speed tables) to various subpages of a WP:JS project. Of course, as much as I like the idea (honestly, a place to store real JavaScript optimization tips -- sign me up!), I wonder how much relevance it has to a WP project.
:::Though, we COULD always start up an actual JavaScript optimization article (not a guide, but rather a "list" of sorts). [[User:SG|♠ SG]] [[User talk:SG|→Talk]] 08:06, 29 December 2006 (UTC)
::::I guess it could just be part of [[Wikipedia:WikiProject User scripts]], since the people interested in site-wide JS are pretty much here on this talk page. [[User talk:Mike Dillon|Mike Dillon]] 19:50, 29 December 2006 (UTC)
== Main page fix ==
rewrote the main page fix as follow:
<pre>
/** Main Page Append Complete list Link *******************************************************
*
* Description: Adds a link to the complete list of languages available of the main page.
* Maintainers: [[User:AzaToth]]
*/
if ( wgPageName == 'Main_Page' && wgIsArticle ) {
// Add a "Complete list" link to the "in other languages" box on the main page,
// using some very unstable Javscript.
function mainPageAppendCompleteListLink() {
try {
var node = document.
getElementById( "p-lang" ).
getElementsByTagName('div')[0].
getElementsByTagName('ul')[0];
var strongNode = document.createElement( 'strong' );
var aNode = document.createElement( 'a' );
var liNode = document.createElement( 'li' );
strongNode.appendChild( document.createTextNode( 'Complete list' ) );
aNode.setAttribute( 'href' , 'http://meta.wikimedia.org/wiki/List_of_Wikipedias' );
aNode.appendChild( strongNode );
liNode.appendChild( aNode );
node.appendChild( liNode );
} catch(e) {
// lets just ignore what's happened
return;
}
}
addOnloadHook( mainPageAppendCompleteListLink );
}
</pre>
<sub>→[[User:AzaToth|<span style="color:#773">Aza</span>]][[User_talk:AzaToth|<span style="color:#359">Toth</span>]]</sub> 22:48, 28 December 2006 (UTC)
:Nice work. There is a typo in your comment in the catch block ("happend" for "happened"), and there is no need to recheck <code>wgTitle</code> in <code>mainPageTransform</code>, since it only executes if the title is "Main Page". [[User talk:Mike Dillon|Mike Dillon]] 22:54, 28 December 2006 (UTC)
::Hehe, yea, I had (or still have) problem finding exact when it should be executed and when not. <sub>→[[User:AzaToth|<span style="color:#773">Aza</span>]][[User_talk:AzaToth|<span style="color:#359">Toth</span>]]</sub> 23:11, 28 December 2006 (UTC)
:::Not sure about when it should be executed or not, since the old version is pretty hard to decipher. I was mainly saying that if the outer if statement already checks <code>if ( wgTitle == 'Main Page' )</code>, then the hooks will only be added when that condition is true and it doesn't need to be rechecked inside the hook function itself.
:::BTW, thanks for deciding to maintain this thing. [[User talk:Mike Dillon|Mike Dillon]] 23:14, 28 December 2006 (UTC)
::::Yea, I thought about that, but the only problem is that I'm not admin (yet for the millionth time), so I can't make edits directly. <sub>→[[User:AzaToth|<span style="color:#773">Aza</span>]][[User_talk:AzaToth|<span style="color:#359">Toth</span>]]</sub> 23:53, 28 December 2006 (UTC)
:::::I was just referring to the fact that you stuck your name on the "maintained by" comment. Just because you can't edit it doesn't mean you don't maintain it. I'm involved with "maintaining" plenty of stuff at work, but the QA team still has to approve releases and the operations team has to actually make the changes ;) [[User talk:Mike Dillon|Mike Dillon]] 01:48, 29 December 2006 (UTC)
:::: I've [http://en.wikipedia.org/w/index.php?title=MediaWiki_talk%3ACommon.js&diff=97028881&oldid=97023349 changed] the check done to make sure the script is only executed on the main page. I'm puzzled by what mainPageTransform does, though. Shouldn't both the if and else if check for mpSmallEnabled (instead of !mpSmallEnabled?)
Those EnWpMp* things seems to be left-overs from [[Wikipedia:WikiProject Usability]] and aren't actually used on the current main page. —''[[User:R._Koot|Ruud]]'' 00:02, 29 December 2006 (UTC)
:Then we just remove that part, if it's unnecessary. <sub>→[[User:AzaToth|<span style="color:#773">Aza</span>]][[User_talk:AzaToth|<span style="color:#359">Toth</span>]]</sub> 02:08, 29 December 2006 (UTC)
== mainPageRenameNamespaceTab() ==
I think it's a bad habit of using ''innerHTML'' as it's a rather expensive operation, following code should work as well I belive:
function mainPageRenameNamespaceTab() {
try {
document.getElementById( 'ca-nstab-main' ).firstChild.textContent = 'Main Page';
} catch(e) {
return;
}
}
<sub>→[[User:AzaToth|<span style="color:#773">Aza</span>]][[User_talk:AzaToth|<span style="color:#359">Toth</span>]]</sub> 13:48, 29 December 2006 (UTC)
: Fixed. —''[[User:R._Koot|Ruud]]'' 14:45, 29 December 2006 (UTC)
::Actually, Internet Explorer does NOT support textContent, but rather uses innerText. You need to test for innerText first, and then use textContent if that fails. I suggest setting a global var for this, so you don't have to keep testing every time you want to change the text of something. [[User:SG|♠ SG]] [[User talk:SG|→Talk]] 18:28, 29 December 2006 (UTC)
:::Oh, I thought also IE did handle DOM level 3. We dont need to test for it before, we just do it in the catch <sub>→[[User:AzaToth|<span style="color:#773">Aza</span>]][[User_talk:AzaToth|<span style="color:#359">Toth</span>]]</sub> 18:45, 29 December 2006 (UTC)
function mainPageRenameNamespaceTab() {
try {
node = document.getElementById( 'ca-nstab-main' ).firstChild;
try {
node.textContent = 'Main Page'; // Per DOM Level 3
} catch(e) {
node.innerText = 'Main Page'; // IE doesn't handle .textContent
}
} catch(e) {
// node not found
}
}
:::This needs to use <code>var node</code>, or else it leaks out of the function. [[User talk:Mike Dillon|Mike Dillon]] 19:45, 29 December 2006 (UTC)
So IE didn't like it? try this then:
<pre>
function mainPageRenameNamespaceTab() {
try {
var node = document.getElementById( 'ca-nstab-main' ).firstChild;
if( Element.textContent ) {
node.textContent = 'Main Page'; // Per DOM Level 3
} else if( Element.innerHTML ) {
node.innerHTML = 'Main Page'; // IE doesn't handle .textContent
} else {
node.replaceChild(node.firstChild, document.createTextNode('Main Page')); // Fallback
}
} catch(e) {
// bailing out!
}
}
</pre>
<sub>→[[User:AzaToth|<span style="color:#773">Aza</span>]][[User_talk:AzaToth|<span style="color:#359">Toth</span>]]</sub> 23:55, 29 December 2006 (UTC)
: innerHTML works fine, maybe the problem lies in IE's try/catch handling? —''[[User:R._Koot|Ruud]]'' 00:05, 30 December 2006 (UTC)
::Don't use innerHTML; use innerText. It's much, much faster for modifying the text of a node. [[User:SG|♠ SG]] [[User talk:SG|→Talk]] 05:14, 30 December 2006 (UTC)
== Import Module ==
As we now have a Common.js, we could include this module here, to be used for user created modules, was rejected before in Monobook.js because it should be able to be used by everyone, and not only those who where using monobook. <sub>→[[User:AzaToth|<span style="color:#773">Aza</span>]][[User_talk:AzaToth|<span style="color:#359">Toth</span>]]</sub> 17:52, 29 December 2006 (UTC)
/** Import Module *************************************************************
*
* Description: Includes a raw wiki page as javascript,
* used for including user made modules as scripts
* Maintainers: [[User:AzaToth]]
*/
function import_module( page ){
try {
var url = wgServer + wgArticlePath.replace( '$1' , escape( page ) ) + '?action=raw&ctype=text/css';
var scriptElem = document.createElement( 'script' );
scriptElem.setAttribute( 'src' , url );
scriptElem.setAttribute( 'type' , 'text/javascript' );
document.getElementsByTagName( 'head' )[0].appendChild( scriptElem );
} catch( e ) {
return;
}
}
:* Maybe there should be two functions: <code>import_script</code> and <code>import_stylesheet</code>?
:* The URL isn't correct: this should be <code>wgScriptPath + "/index.php?title=" + escape( page.replace( " ", "_" ) ) + "&amp;action=raw&amp;ctype=text/javascript&amp;dontcountme=s"</code>.
:* I don't think silently ignoring any errors is the correct thing to do in this case.
:* I've added another feature to [[User:R._Koot/monobook.js|my own import function]], don't know if it's useful. —''[[User:R._Koot|Ruud]]'' 21:59, 29 December 2006 (UTC)
::The "<code>&amp;</code>" is not correct, since this is in JavaScript, not HTML. [[User talk:Mike Dillon|Mike Dillon]] 22:04, 29 December 2006 (UTC)
::: No it's a string in JavaScript that is outputted as HTML. See the source of this page and see how your personal stylesheet is included. —''[[User:R._Koot|Ruud]]'' 22:25, 29 December 2006 (UTC)
::::That's simply not true. This file is included from a script tag with an src attribute. It is not HTML. [[User talk:Mike Dillon|Mike Dillon]] 22:27, 29 December 2006 (UTC)
Here's what it looks like:
<pre><nowiki>
<script type="text/javascript" src="/w/index.php?title=-&action=raw&smaxage=0&gen=js"><!-- site js --></script>
</nowiki></pre>
The source text of the src is interpreted as pure JS, not HTML. [[User talk:Mike Dillon|Mike Dillon]] 22:28, 29 December 2006 (UTC)
: (Despite the <code><nowiki></code> tags, the <code>&amp;s</code> got lost in your code above.) The extra &amp;s have disappeared in FF's DOM inspector as well, so it indeed seems that the JS src attribute is not interpreted literally as the HTML src attribute. —''[[User:R._Koot|Ruud]]'' 22:37, 29 December 2006 (UTC)
::Yeah, I saw that. Weird. Anyways, the escaping is a source-level thing. By the time you're in the DOM, everything is raw characters. Escaping ampersands in JavaScript code is only necessary if the code itself is in a raw script tag in the HTML without a CDATA wrapper. Even then, browser quirks let you get away with not escaping there even. [[User talk:Mike Dillon|Mike Dillon]] 22:44, 29 December 2006 (UTC)
I saw that these were added, which is really cool. Two things though:
# The <code>page.replace(" ", "_")</code> is not necessary; <code>escape(page)</code> will make a valid "title" param that MediaWiki can understand
# The <code>CDATA</code> stuff in the body of the "style" tag is not needed
Neither of these things will break anything, but they aren't doing anything useful either. As I said, a plain escaped title will work fine. The CDATA thing will just be ignored because the CSS parser sees them as comments. [[User talk:Mike Dillon|Mike Dillon]] 15:30, 31 December 2006 (UTC)
: The CDATA will cause the browser's XML parser not to parse the stylesheet, which is invalid XML due to the presence of ampersands. —''[[User:R._Koot|Ruud]]'' 18:21, 31 December 2006 (UTC)
::This won't go through the XML parser. It's in raw JavaScript code and direct additions to the DOM are by necessity pre-parsed. It won't have any effect one way or the other. [[User talk:Mike Dillon|Mike Dillon]] 18:29, 31 December 2006 (UTC)
::: Makes sense (and it's stated in the DOM specification). —''[[User:R._Koot|Ruud]]'' 18:36, 31 December 2006 (UTC)
== Possible solution to {{tl|click}}? ==
Because {{tl|click}} is an ugly hack, and messes up screen readers, etc. why not make a JS version?
The benefits would be:
*If something like a screen reader was being used, it would just not execute the js and no harm done
*There are some browsers that have trouble rendering things like this, but would have no problem using js
*..please add more..
Here is a prototype:
<pre>
/** Click on Image ***********************************************************
*
* Description: Make images clickable to a different ___location
* than the one set by MediaWiki
* Maintainers: [[User:GeorgeMoney]]
*/
addOnloadHook(function() {
var usebody = document.getElementById('bodyContent') || document;
var divs = usebody.getElementsByTagName('div');
for(var i = 0; i < divs.length; i++) {
try {
if(divs[i].getAttribute('class') != 'click') continue;
var titleurl = divs[i].getAttribute('title').split('URL=');
divs[i].getElementsByTagName('a')[0]
.setAttribute('title', titleurl[0]);
divs[i].setAttribute('title', '');
if(typeof titleurl[1] == 'undefined') continue;
var useurl;
if(titleurl[1].substr(0, 2) == '[['
&& titleurl[1].substr(titleurl[1].length-2) == ']]') {
useurl = titleurl[1].substr(0, titleurl[1].length-2).substr(2);
useurl = wgServer + wgArticlePath.replace('$1', useurl);
} else
useurl = titleurl[1];
divs[i].getElementsByTagName('a')[0]
.setAttribute('href', useurl);
} catch(e) { }
}
});
</pre>
so you would type <code><nowiki><div class="click" title="title to be set after javascript parses URL=http://example.com">[[Image:Myimage]]</div></nowiki></code>
Which would then set the href (url) of the link which contains the image to http://example.com, and link's title to "title to be set after javascript parses".
Using wikilinks on the link works too.
I know this might sound complicated, but it is actually quite simple.
[[User:GeorgeMoney|GeorgeMoney]] ([[User talk:GeorgeMoney|talk]]) 04:52, 3 January 2007 (UTC)
: This doesn't solve the copyright info problem. — [[User:Omegatron|Omegatron]] 15:21, 3 January 2007 (UTC)
::I guess to solve the copyright problem we could set the title of the link to the old link's href, like "Please see foo for copright info", or maybe even have it append fromimage=true&oldimage=foo which could add in the contentSub "For information on the image that refered you here, see: foo", etc.. [[User:GeorgeMoney|GeorgeMoney]] ([[User talk:GeorgeMoney|talk]]) 23:54, 3 January 2007 (UTC)
:::That wouldn't work on the Main Page, where {{[[Template:click|click]]}} is used to link a picture of Wiktionary's logo to Wiktionary, etc.. --[[User:ais523|ais523]] 15:17, 9 January 2007 ([[User:ais523|U]][[User talk:ais523|T]][[Special:Contributions/Ais523|C]])
| |||