MediaWiki talk:Common.js/Archive 9

Disable overflow in printable version of page

I thought after the deletion of template:scrollref that it was determined that it would be too difficult to block scrollboxes from rendering in the printable layout of pages, but it seems like it would be fairly simple now: [1]. Would someone mind implementing the change? Any time that a div tag has the overflow flag set and obscures content, print users will not be able to see any obscured content in the present form. Doing this via templates has been disabled in Main namespace on the en wiki, but is still in use in the it wiki, as I understand it. At present, a dozen or so user and talk pages are unprintable here, but several real pages are unprintable elsewhere do to Template:scrollbox, but lord only knows how many are using subst'd equivalents or directly put in the div tag. Is there any reason not to make with the fix in the diff linked above? Thanks, MrZaius^talk 20:38, 19 July 2007 (UTC)

That change would not be made by a sysop on this page, it'd be made by a developer on /skins-1.5/common/commonPrint.css, which is not on-wiki. — Madman bum and angel (talk – desk) 14:23, 20 July 2007 (UTC)

Would @media print work? Gracenotes^T § 22:59, 20 July 2007 (UTC)

I'm not sure if that last comment implies a fix is possible here w/o buggin' the devs, but I believe this change should be made to MediaWiki proper, if the same problem is applicable to all other installations. Reported here: http://bugzilla.wikimedia.org/show_bug.cgi?id=10654 If I borked the description, would someone mind responding and clarifying? Thanks for all your help, MrZaius^talk 17:10, 21 July 2007 (UTC)

The devs seem unwilling or unable to fix the problem. Do we have a fix we can implement here? MrZaius^talk 20:51, 24 July 2007 (UTC)

I agree with the comments Simetrical makes at Bugzilla. If we specify a fixed height/scrollable overflow somewhere it should be done properly (e.g. use a CSS class from Common.css and specify an alterative for @media print). However, I doubt scrollboxes have any legitimate uses for the same reasons that {{scrollref}} was deleted. Where are they still used? —Ruud 22:32, 24 July 2007 (UTC)

On the en wiki, primarily user pages and talk pages. On the Italian wiki, they at least were used for a handful of galleries. Furthermore, not a month goes by without editors on the en wiki popping up the raw code on articles, ignoring the {{scrollref}} TfD. That said, I wouldn't have been surprised at all to see scrollref survive TfD if it hadn't broken printable layouts and raised accessibility concerns. {{scrollbox}} is still in use, although it too has been flagged for TfD by a nom that is solely concerned about this very issue. If it is being used correctly, great - fix it so that it can be safely used without breaking accessibility. If not, block the raw code in main and other namespaces alike. Go halfway, and this will just keep coming up over and over again. MrZaius^talk 01:00, 25 July 2007 (UTC)

Common.css and Common.js are not used on the Printable version. Even if they were, this would be for Common.css, not Common.js. — Madman bum and angel (talk – desk) 02:01, 25 July 2007 (UTC)

Does that mean there's no possible rendering fix without dev involvement and no way to completely block overflow from rendering sitewide? If that's the case, seems like we're back to the bot idea and I'd better switch my keep to a delete on {{scrollbox}}'s TfD. MrZaius^talk 02:22, 25 July 2007 (UTC)

They are used on the printable version. —Ruud 12:41, 25 July 2007 (UTC)

My apologies. You are, of course, correct; I hadn't read enough of the page source. — Madman bum and angel (talk – desk) 15:06, 30 July 2007 (UTC)

Readonly

In the section for the "Main page is unavailable" image, I am proposing to add the following lines of code into Common.js just in case a vandal was smart enough to load the editform directly, without needing an edit tab.

var makeReadOnly = document.getElementById("wpTextbox1");
makeReadOnly.readOnly = true;

This code should, of course, by put inside the main function for "The Main Page is unavailable" tweaks. —« ANIMUM » 16:45, 11 August 2007 (UTC)

As another option, adding "newarticletext" as a triggering elementId would activate the script even if they click an edit link. An enterprising vandal might then disable JS, but as Main Page is transcluded onto ten cascade-protected pages, this would do them little good. – Luna Santin (talk) 18:20, 11 August 2007 (UTC)

Or we could use the last function that I've installed in my monobook, for extra precaution, etc. –Animum 15:52 12 August 2007 (UTC)

WikiMiniAtlas

WikiMiniAtlas is a GoogleMaps-like draggable, zoomable, and clickable worldmap which displays geocoded Wikipedia articles. WikiMiniAtlas, unlike Google maps, is free content/software and written by one of our own, Dschwen. You can try Wikiminiatlas here.

When WikiMiniAtlas embedding is enabled it displays a little blue globe next to coordinates in articles. Clicking on the globe brings up the popup map. The embedding approach is the same as is used in our popup mediaplayer, because I stole the popup code from Dschwen. Nothing is loaded from the mapping server until the user clicks on the globe.

A commons specific version (which displays overlayed images) has been in the global configuration on commons for several months now. The Wikipedia version is in the global configurations for both pt wikipedia and it Wikipedia.

Does anyone have any objections to making this useful feature globally available on English Wikipedia? --Gmaxwell 21:28, 13 August 2007 (UTC)

It looks pretty good to me (as long as it's thoroughly tested etc). Commons:Image:Erioll world.svg and other images used in the user interface would need to be protected as their usage across the many location-specific articles in Wikipedia would make them very high-risk. Also, it might be nice to link to a page describing and linking to the sources for the various maps available, perhaps from the options screen? Tra (Talk) 22:51, 13 August 2007 (UTC)

Image is now protected, geesh, thanks for catching that oversight. How about just a link on the options screen to take people to, say, a page on meta describing WikiMiniAtlas (which would basically be a copy of User:Dschwen/WikiMiniAtlas)? --Gmaxwell 01:40, 14 August 2007 (UTC)

Yes, a page on meta sounds good. I had originally thought of putting something in Wikipedia: namespace, but if it's used on other projects as well, meta would be more useful to allow it to be updated centrally for all of them (and would mean that the same link can be used across all the projects). Tra (Talk) 01:58, 14 August 2007 (UTC)

Moving the whole stuff, including the script (which is the same for all projects, and handles UI language and displayed data dynamically) to meta would be a good idea. The Wikiminiatlas page could then easily be translated to several languages (some translations alredy exist), and the JS popup could link to those translated pages (i.e. meta:WikiMiniAtlas/en). We could get rid of the installation instructions and instead focus more on data-source citations and utilized software. --Dschwen 08:38, 14 August 2007 (UTC)

Sounds like an excellent alternative to Google Maps, which we should purge as soon as possible. --Cyde Weys 01:36, 14 August 2007 (UTC)

• In-house software is preferable to other alternatives, so yeah, I support this as well. My only concern is about load issues. Can it handle the added visits? Titoxd^{(?!? - cool stuff)} 00:26, 15 August 2007 (UTC)
  • The load profile is not unlike that of the popup media-player. The popup media player produces an almost unmeasurable load. I do not, speaking with the sysadmin hat on, expect any issues. If there are any we can fairly easily spread the mapping across more systems, which is something we should eventually do in any case there hasn't yet been a need. --Gmaxwell 00:30, 15 August 2007 (UTC)
    • Then I have no concerns. Feel free to turn it on anytime. Titoxd^{(?!? - cool stuff)} 00:31, 15 August 2007 (UTC)

Sounds good to me, please turn it on. ←Ben^B4 00:55, 15 August 2007 (UTC)

Okay.. well as soon as Dschwen sets up a final home for it on meta. I think that was a good idea, since the tool is already made for multi-site use. --Gmaxwell 04:17, 15 August 2007 (UTC)

I was just getting started, but if the script is to reside on meta too, I'd rather put it into the MediaWiki namespace so that only admins can edit it. And I'm not yet an admin on meta...

Also I'll familiarize myself with the multilingual-pages system on meta, commons uses subpages for some translations, but meta doesn't seem to have them enabled in namespace zero and that's what I'll do :-). --Dschwen 07:22, 15 August 2007 (UTC)

With temporary sysop-privileges I moved the script to meta:MediaWiki:Wikiminiatlas.js. The doc pages are located at meta:WikiMiniAtlas. I'll redesign the docs to reflect the fact that the Atlas is enabled by default. I'd say you can go ahead an enable it. --Dschwen 15:11, 16 August 2007 (UTC)

Exporting table collapse code

Hello, I recently tried to export the table collapse code to another wiki (wiki.xentax.com), but I can't get it to work. I have the distinct feeling that I'm missing something obvious, but I don't have the knowledge necessary to figure out what. You can see what code I exported on MediaWiki:Common.js, what CSS I've copied on MediaWiki:Common.css, and my test page. I would greatly appreciate any help, and thanks in advance! --Dinoguy1000 ^Talk 18:45, 4 August 2007 (UTC)

You're using a pretty old version of MediaWiki and it doesn't use MediaWiki:Common.js. You should be able to try putting the code in MediaWiki:Monobook.js, but I'd actually recommend upgrading to the latest release of MediaWiki if possible. Mike Dillon 19:38, 4 August 2007 (UTC)

You are using an old version of MediaWiki which doesn't support common.js yet. Try moving the code to monobook.js. —Ruud 19:41, 4 August 2007 (UTC)

I was previously aware of the version of MW being used; I was not, however, aware that it doesn't support Common.js. Since it's not actually my wiki (and I don't have server-side file access), I can't update the software myself, though I have requested an upgrade of the site owner and was told that it's being worked on. In the meantime, I'll try using Monobook.js. Thanks for your help, and patience with me! --Dinoguy1000 ^Talk 16:42, 9 August 2007 (UTC)

Hmm, it seems that it still doesn't want to work for me, despite the fact that I moved the code to MediaWiki:Monobook.js. Any suggestions? --Dinoguy1000 ^Talk 01:19, 12 August 2007 (UTC)

A simple look at the JavaScript error console shows that you did not port it over entirely. It depends on other functions, such as hasClass. Make sure you have all of them in there. Use a browser that offers you access to a decent JavaScript debugger and you'll be fine. ♠ SG →Talk 01:47, 12 August 2007 (UTC)

All right, I copied hasClass over and it seems to be working now. If I'm still missing something, please tell me, since I really don't have much experience with debuggers (and the one I use isn't reporting any errors now). Thanks for your help! --Dinoguy1000 ^Talk 04:37, 17 August 2007 (UTC)

importScript() and Wikimediaplayer.js

Is there any opposition to:

1. Adding an optional maxage parameter to importScript() and importStylesheet(), applied as:

   if (typeof maxage != 'undefined') {
       url += "&smaxage=" + encodeURIComponent(maxage);
   }
   

2. Replacing the current code used to pull in Mediawiki:Wikimediaplayer.js with:

   importScript('Mediawiki:Wikimediaplayer.js', 86400);
   

Any potential problems I may have overlooked? —Ilmari Karonen (talk) 14:37, 17 August 2007 (UTC)

1. We could also use just one static maxage value for all imported scripts, or would that cause problems?

1. Now I think of it, isn't smaxage deprecated?

1. The wikiministlas is located at meta.wm, while importScript() only loads pages from en.wp. A local copy might save a DNS lookup and HTTP connection. Otherwise importScript() needs to be extended to be able to handle scripts located on other domains.

1. Oh wait, I see we are talking about wikimediaplayer. The comment is still valid, though.

—Ruud 20:26, 19 August 2007 (UTC)

Next version of the mediaplayer will likely be meta hosted as well. It's become a pain to maintain it on so many sites. :) --Gmaxwell 22:48, 19 August 2007 (UTC)

For the collapsible table, include the brackets in the show/hide link

For the collapsible table, it would look better and improve formatting if the square brackets were included in the show/hide link to uncollapse/collapse the table. This is the case for the Dynamic Navigation bars, but I would like to see it extended to the collapsible table also. One problem with not linking them is that when the text color of the header in a collapsible table is changed, the color of the square brackets changes, but not the color of the show/hide link. Thus, whenever the text color is changed, the table looks funny. Simply adding the brackets to the link would fix this problem and fix all of the instances where collapsible tables are used with different text colors in the title.

Unfortunately, I'm not very familiar with this code and am not able to post the fix myself, but hopefully someone else can help modify the code to do this (it seems like a simple change). Thanks, --CapitalR 13:26, 21 August 2007 (UTC)

{{editprotected}}

Specific request: Please change:

 var collapseCaption = "hide";
 var expandCaption = "show";

to:

 var collapseCaption = "[hide]";
 var expandCaption = "[show]";

and change:

             Button.appendChild( document.createTextNode( "[" ) );
             Button.appendChild( ButtonLink );
             Button.appendChild( document.createTextNode( "]" ) );

to:

             Button.appendChild( ButtonLink );

and change:

  var NavigationBarHide = '[' + collapseCaption + ']';
  var NavigationBarShow = '[' + expandCaption + ']';

to:

  var NavigationBarHide = collapseCaption;
  var NavigationBarShow = expandCaption;

Thank you. ←Ben^B4 13:45, 21 August 2007 (UTC) (modified by --CapitalR 14:01, 21 August 2007 (UTC))

Not linking the brackets is consistent with the [edit] links and the [show]/[hide] button in the table of contents. The colour of the brackets should be the same as the textcolour of the table header, though. —Ruud 14:33, 21 August 2007 (UTC)

Well, the unlinked brackets are ugly in the table of contents too. --David Göthberg 14:39, 21 August 2007 (UTC)

I'm withdrawing this request for now -- it seems we should make things consistent, and the easiest way to do that would be to make the NavToggles uglier with the link inside the brackets. There's no way we can make the toggle the same color as the header text, they're separate elements and the text style is variable. ←Ben^B4 18:25, 21 August 2007 (UTC)

I could be copied over using some javascript, on the other hand I don't see any reason for people to override the default colours of navigational boxes in the first place (totally breaks when there are multiple navboxes in a single article / makes it nearly impossible to make the style skin-dependant). —Ruud 19:01, 21 August 2007 (UTC)

Wikiminiatlas bugged?

Yeah, I understand it might be a nifty little feature, but could we hold off adding it until it becomes stable and tested? The most recent edit made it unusable (pokes the error console on every page), as described here. Миша13 20:59, 21 August 2007 (UTC)

It was the innocent looking application of a translation patch. Yep, I slipped, I try to add new translations quickly to enhance accessability for new users. Always worked before, but it is just that seemingly easy stuff that asks for trouble. Anywho, I created a staging copy now, better late than never. You are welcome to do more of the testing you asked for, but the WMA exists for 1.5 years now and it needs constant development as new features keep getting asked for. I am currently reworking the server-side part and the parts of the JS that are located on the toolserver (all on staging copies), that stuff gets a lot of testing but will eventually be put live. I need the feedback, so I have difficulties imagining a stable with, what, a release once a year? --Dschwen 21:54, 21 August 2007 (UTC)

template:Scroll gallery

A system admin of the French wiki fr:Utilisateur:Pabix has created a template fr:Modèle:Images that allows to create slideshows on wikipedia: i.e. slideshow of maps about the 2nd Battle of El Alamein.
The template uses some java extensions and has (so far) also been adapted for the Italian wiki it:Template:Galleria. Yesterday I tried to import it to the English Template:Scroll gallery and German wiki de:Vorlage:Scroll Gallery, but it would not work. Today I was informed by Italian wiki user it:utente:Twice25 that the follwoing java script needs to be added to either MediaWiki:Common.js or MediaWiki:Monobook.js for the template to work. Would this be possible to do? Thanks, --noclador 00:54, 20 August 2007 (UTC)
I copied the script that needs to be added below and it looks as it should, but it comes out all distored in the saved text- therefore here you can find the link as the script appears in the Italian it:MediaWiki:Monobook.js (it is the last at the bottom of the page) and here is a link to the change that was made in the Italian wiki to insert the script: [2]

/*** CODE FOR TEMPLATE:Scroll gallery ***/
function toggleImage(group, remindex, shwindex) {
  document.getElementById("ImageGroupsGr"+group+"Im"+remindex).style.display="none";
  document.getElementById("ImageGroupsGr"+group+"Im"+shwindex).style.display="inline";
}
function ImageGroup(){
	if (document.URL.match(/printable/g)) return;
	var bc=document.getElementById("bodyContent");
	var divs=bc.getElementsByTagName("div");
	var i = 0, j = 0;
	var units, search;
	var currentimage;
	var UnitNode;
	for (i = 0; i < divs.length ; i++) {
		if (divs[i].className != "ImageGroup") continue;
		UnitNode=undefined;
		search=divs[i].getElementsByTagName("div");
		for (j = 0; j < search.length ; j++) {
			if (search[j].className != "ImageGroupUnits") continue;
			UnitNode=search[j];
			break;
		}
		if (UnitNode==undefined) continue;
		units=Array();
		for (j = 0 ; j < UnitNode.childNodes.length ; j++ ) {
			var temp = UnitNode.childNodes[j];
			if (temp.className=="center") units.push(temp);
		}
		for (j = 0 ; j < units.length ; j++) {
			currentimage=units[j];
			currentimage.id="ImageGroupsGr"+i+"Im"+j;
			var imghead = document.createElement("div");
			var leftlink;
			var rightlink;
			if (j != 0) {
				leftlink = document.createElement("a");
				leftlink.href = "javascript:toggleImage("+i+","+j+","+(j-1)+");";
				leftlink.innerHTML="◀";
			} else {
				leftlink = document.createElement("span");
				leftlink.innerHTML=" ";
			}
			if (j != units.length - 1) {
				rightlink = document.createElement("a");
				rightlink.href = "javascript:toggleImage("+i+","+j+","+(j+1)+");";
				rightlink.innerHTML="▶";
			} else {
				rightlink = document.createElement("span");
				rightlink.innerHTML=" ";
			}
			var comment = document.createElement("tt");
			comment.innerHTML = "("+ (j+1) + "/" + units.length + ")";
			with(imghead) {
				style.fontSize="110%";
				style.fontweight="bold";
				appendChild(leftlink);
				appendChild(comment);
				appendChild(rightlink);
			}
			currentimage.insertBefore(imghead,currentimage.childNodes[0]);
			if (j != 0) currentimage.style.display="none";
		}
	}
}
addOnloadHook(ImageGroup);

Looks great, but I think there's a problem when you scroll to the last image. Try going to image 16 of 16 on it:Seconda battaglia di El Alamein#La battaglia. It doesn't display. —METS501 (talk) 00:59, 20 August 2007 (UTC)

Strange... I tried to replace the 16th image with the 1st image and the 1st was displayed correctly... than i changed the resolution to 399px and now the 10th image does not work, but the 16th does... but all images have tge same size: 1153x1153px ???? with 404px they work now all :-) --noclador 01:12, 20 August 2007 (UTC)

Aren't we not supposed to disrupt printing like that? I know there are specific instrtuctions against scrollbars on references, and this seems very similar. A nice idea, but ordinary gallery tags are better for our purposes. ←Ben^B4 01:47, 20 August 2007 (UTC)

ordinary gallery tags are totally different. The above script produces a kind of animation that allows the reader to click through the a series of images and thus to comprehend easier the dynmaics of i.e. a battle or the workings of an engine. I think that a long series of images is much more disruptive to an article than this- i.e. Second battle of El Alamein#The battle. About printing: what about animated gifs? --noclador 11:54, 20 August 2007 (UTC)

I would like to know if the above script will be included in the MediaWiki:Common.js or not, as without it I'm unable to include the slideshow of maps about the 2nd Battle of El Alamein into the article Second battle of El Alamein#The battle. Any info about what the status is of the script would be appreciated. --noclador 11:45, 27 August 2007 (UTC)

Problem with nested collapsible tables

Nesting collapsible tables while using the autocollapse feature has been giving me some problems. Note that in the example below (which should start out in a collapsed state), when you press the Show button, the child tables start out in uncollapsed mode, but the buttons display "show" instead of "hide". I think that the child tables should start out in collapsed mode when the parent table is uncollapsed. This occurs on Firefox for XP/Vista (and I think on IE also). Can someone either show me the correct way to nest tables, or tell me if there is a problem in the collapsible code? Thanks, --CapitalR 14:00, 22 August 2007 (UTC)

<table class="navbox collapsible autocollapse">
<tr><th>Title1</th></tr>
<tr><td><!--http://wiki.riteme.site/wiki/MediaWiki:Common.js
Message

--><table class="navbox collapsible collapsed">
<tr><th>Title1</th></tr>
<tr><td>Text1</td></tr></table><!--

--><table class="navbox collapsible collapsed">
<tr><th>Title1</th></tr>
<tr><td>Text1</td></tr></table><!--

--></td></tr></table>

I never designed the code with nesting in mind, and as far as I am aware it doesn't work. I'm still planning to rewrite the code to allow multiple headers in a single table which can be hidden and shown separately. Could you give any concrete examples where nesting collapsible tables would be useful? —Ruud 16:12, 22 August 2007 (UTC)

Thanks for the reply. I think that making multiple collapsible headers in a table would fix the problem in most cases. I just converted about 5000 templates to use the collapsible table class, and noticed that about 30-40 of them now have nested collapsible tables, which don't quite work correctly. One major disaster is {{Anatolian Seljuk Sultanate and Anatolian Turkish Beyliks}}. This relies heavily on the nesting to collapse a giant navbox into a small bar, but when the parent navbox is uncollapsed it would be nice to just see all of the child navboxes collapsed so only one at a time can be uncollapsed manually. --CapitalR 16:38, 22 August 2007 (UTC)

Oh my... that "navagation box" needs some rethinking. —Ruud 17:05, 22 August 2007 (UTC)

Yup, I'll second that. --CapitalR 17:19, 22 August 2007 (UTC)

I had brought up this same issue at WP:VPT a while ago. (ATM it's still the first discussion on the page.) It took me a while to come up with something, since I've never worked with JS or the DOM before, but in the end it seemed to me that a one-line change to the code would enable nesting to work as expected (albeit not necessarily as documented). I put this proposal up at VPT too, and it just scrolled off having received no comment.

The only thing that keeps nesting from working is that the line in collapseTable

     var Rows = Table.getElementsByTagName( "tr" );

grabs all rows below Table in all its descendants. However, if it was to grab only the rows that are direct children of Table, nesting works just fine. So instead:

     var Rows = Table.rows;

I've tested this out in my monobook.js in both Firefox 2.0 and IE6 and it appears to work.

In my case, the impetus for wanting to nest tables came from the vociferous arguments that flare up from time to time at Template:Books of the Old Testament, where issues of what version of what book is in whose canon, and which should be included in the template and which should not (inevitably, someone feels slighted) often take up the bulk of the talk page. Nesting the tables would enable a template that's all-inclusive, but which would not necessarily have to be so long in the display as to be unwieldy. It would also enable the elimination of every other Judaeo-Christian religion/denomination-specific template on the Biblical canon since in every case the main template can then be used with only the relevant portion expanded by default. (And also enable the inclusion of the Jewish canon as such, without POV language such as "Old Testament" in the title.) Ugly, but so are the arguments, so I'd hope this approach would render the arguments moot and encourage people to spend their energies more on, you know, writing an encyclopedia.

How generally useful this would be I can't say, but since it seems to be a relatively simple change is it doable anyway? TCC (talk) (contribs) 23:26, 24 August 2007 (UTC)

{{editprotected}} per the above. By the way, I didn't test this in the context of a navbox, but I don't see that there would be much difference. TCC (talk) (contribs) 00:46, 28 August 2007 (UTC)

 Done Graham87 12:11, 28 August 2007 (UTC)