Last modified: 2014-04-16 03:13:59 UTC
Does MediaWiki core still need a "printable version" feature? We currently support a URL parameter (&printable=yes) and sidebar user interface exposure ("Printable version"). It's unclear whether either are really necessary these days. Real-world stats might help here. Related: * bug 48234 * bug 56786
(In reply to comment #0) > Does MediaWiki core still need a "printable version" feature? We currently > support a URL parameter (&printable=yes) and sidebar user interface exposure > ("Printable version"). It's unclear whether either are really necessary these > days. Real-world stats might help here. > > Related: > > * bug 48234 > * bug 56786 If I recall, it was because people yelled and screamed about us not having it. The printable version link actually does nothing, since print stylesheets automatically are applied regardless of how you are viewing the page For stats, http://stats.wikimedia.org/wikimedia/squids/SquidReportScripts.htm seems to suggest 17M hits for printable type urls (out of 15,254 M I think, not sure if I'm reading that right)
I still use it. E.g., at Mises Wiki we have a customized skin that prints a bunch of junk at the top if you try to print without first clicking to get the printable version. Compare what happens if you do a print preview from: * http://wiki.mises.org/wiki/Main_Page * http://wiki.mises.org/mediawiki/index.php?title=Main_Page&printable=yes Here is the Vector.php we use: http://pastebin.com/QKGARhTU Notice these lines: if ( isset ( $_REQUEST[ 'printable' ] ) ) { require_once ( "Vector.printable.php" ); } else { ... In other words, if the user has selected the printable version, then Vector.printable.php, which is just the regular Vector.php that comes with MediaWiki and doesn't have all that MisesWiki-specific stuff that would cause all that junk to print at the top, is used instead of the rest of the code in Vector.php. If there's a more elegant solution to this issue, please let me know. Thanks.
(In reply to comment #2) > I still use it. E.g., at Mises Wiki we have a customized skin that prints a > bunch of junk at the top if you try to print without first clicking to get > the > printable version. Compare what happens if you do a print preview from: > > * http://wiki.mises.org/wiki/Main_Page > * http://wiki.mises.org/mediawiki/index.php?title=Main_Page&printable=yes > > Here is the Vector.php we use: http://pastebin.com/QKGARhTU Notice these > lines: > > if ( isset ( $_REQUEST[ 'printable' ] ) ) { > require_once ( "Vector.printable.php" ); > } else { ... > > In other words, if the user has selected the printable version, then > Vector.printable.php, which is just the regular Vector.php that comes with > MediaWiki and doesn't have all that MisesWiki-specific stuff that would cause > all that junk to print at the top, is used instead of the rest of the code in > Vector.php. If there's a more elegant solution to this issue, please let me > know. Thanks. That's not a very good argument for keeping printable in. You should be fixing your printable stylesheets properly so that they kill the things you don't want to be printed.
Nathan, that could be trivially solved by adding some print-only styles, by adding a custom ResourceLoader module or even by editing [[mediawiki:print.css]] – and that would in fact be the right way to do this, since it would apply to both the "printable" version and actual printing. All MediaWiki skins are also using this approach to hide irrelevant things when printing, like navigation. Or in other words, I don't think we're supporting your use case.
(In reply to comment #1) > For stats, http://stats.wikimedia.org/wikimedia/squids/SquidReportScripts.htm > seems to suggest 17M hits for printable type urls (out of 15,254 M I > think, > not sure if I'm reading that right) There's some stats. Now is that enough or not? MZMcBride: What's the criteria so it's not "unclear" anymore?
Just link Printable version to the browser print function.
(In reply to comment #6) > Just link Printable version to the browser print function. This is basically bug 22256. When filing this bug, I forgot that Wikimedia wikis (at least some of them) have an extra sidebar section called "Print/export", which really muddies the waters. In MediaWiki core, I think the link should probably be outright killed from the sidebar. On Wikimedia wikis, it would be silly to have a "print/export" section that doesn't include a "print" link. Though the overall utility of a "print/export" sidebar section is very questionable. Blehhh.
After looking at [[User:TheDJ/Print dialog]] (via bug 22256 comment 1), I think putting this script into MediaWiki core may be the best approach. Brian, Gadget850, et al.: thoughts on marking this bug as a duplicate of bug 22256?
I would recommend against removing a visible, findable "printable" link. It's entirely likely that the web UI will become more optimized for, well, *the web* in the future. On mobile we already have collapsible sections (thanks to a decade of "article bloat" making articles so huge people can't just skim them easily on a small screen). I fully expect some sort of sane treatment of references to happen at some point replacing the crappy old "numbered footnote" view that *only* makes sense in print. And as we add more audio, animations, video, and other stuff that doesn't print well we'll need to devise appropriate fallback display for these things meant for print and other static forms. As such, a "printable" view in the future will likely not be just a magic stylesheet -- it may involve DOM transformations, alternate rendering, and importing of additional sections that might not have been loaded and displayed on screen yet.
(In reply to comment #9) I very much hope that this won't happen and that we instead continue providing gracefully degrading content and interface to users who are unable to or choose not to use standard web browsers.
Comment 9 is convincing enough for me. *** This bug has been marked as a duplicate of bug 22256 ***
