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, MrZaiustalk 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? GracenotesT § 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, MrZaiustalk 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? MrZaiustalk 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)
- 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
- The devs seem unwilling or unable to fix the problem. Do we have a fix we can implement here? MrZaiustalk 20:51, 24 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, MrZaiustalk 17:10, 21 July 2007 (UTC)
- Would
- 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. MrZaiustalk 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. MrZaiustalk 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)