Last modified: 2014-02-25 23:45:33 UTC
It seems that the server part of this is already correct. The client just needs to add printable=1 to requests for JS-wrapped CSS should include printable=1, when the page is in print mode (printabable=yes). This is necessary to make sure that screen CSS is omitted and print CSS is not wrapped in @media print for this use case.
Related URL: https://gerrit.wikimedia.org/r/69276 (Gerrit Change I691588c39da7fadeac1ca2ace2c1b769fc4e1bd6)
We didn't pass this to the client and on to load.php because printable pages shouldn't run run any load queue. http://mediawiki.dev/?printable=yes gives me: > #top: > mw.loader.load(["mediawiki.page.startup","mediawiki.legacy.wikibits","mediawiki.legacy.ajax"]); > #bottom: > mw.loader.load(["mediawiki.action.view.postEdit","mediawiki.user","mediawiki.hidpi","mediawiki.page.ready","mediawiki.searchSuggest","mediawiki.page.watch.ajax","ext.vector.collapsibleNav","ext.vector.collapsibleTabs","ext.visualEditor.viewPageTarget","skins.vector.js"],null,true); Which is wrong, those things are not supposed to be loaded on a print page (to avoid e.g. collapsible buttons, "[show]", etc.). Though some of those are hidden by CSS, it'd be better for them to not initialise in the first place. I think this is a regression. If memory serves, not so long ago there were no mw.loader calls on the printable view. Perhaps a change in Skin caused them to be inserted unconditionally? Either way, if there is no other way around it, then the proposed change is good, but I'd prefer to prevent the client-side loader from being set up in the first place (so only the <link only=styles> will run).
(In reply to comment #2) > Which is wrong, those things are not supposed to be loaded on a print page > (to avoid e.g. collapsible buttons, "[show]", etc.). Though some of those are > hidden by CSS, it'd be better for them to not initialise in the first place. Well, if we do that, we need to find an equally simple way to debug the print CSS. There are extensions that are supposed to do it (e.g. https://addons.mozilla.org/en-US/firefox/addon/web-developer/), but it shows the screen *and* print styles. There's probably a good way to do it, just need to find it. More importantly to the average user, we may want to run some JS on the printable=yes view. People sometimes read in that view, and there's some stuff that works in that bare-bones mode. For instance, the reference popups on enwiki (https://en.wikipedia.org/wiki/MediaWiki:Gadget-ReferenceTooltips.js) currently work there, and it seems useful. You can even get the popup to print with some finagling. That illustrates that the print styles apply to the current DOM, not the original HTML source. So even if the JS doesn't run in printable=yes, all the print styles still need to be correct in case they just print directly (without using printable view).
Change 69276 abandoned by Krinkle: ResourceLoader: Pass printable parameter to load.php. Reason: Closing for now. https://gerrit.wikimedia.org/r/69276
Not actively working on this, so putting it back in the pool, but I think the original issue holds. It seems we should either: 1. Pass printable to load.php on printable=yes pages. 2. Not run JS on printable=yes pages (as Krinkle says was the case earlier).
