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)[reply]

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)[reply]

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

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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

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)[reply]
- 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)[reply]
  - Then I have no concerns. Feel free to turn it on anytime. Titoxd^{(?!? - cool stuff)} 00:31, 15 August 2007 (UTC)[reply]

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

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]