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).

In T51722#569487, @Mattflaschen wrote:

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

I agree. In fact, I suspect users that print pages would just print directly. It seems counterintuitive to first open a "Printable version".

Given that we should support printing the view page directly, perhaps it makes sense to remove the "Printable" mode from MediaWiki? The interface to print pages is part of the web browser. Having a control for it seems redundant.

If we want to keep it, we could collect analytics on popularity of printable=yes views in relation to print events (from both printable, and regular mode).

Given that we should support printing the view page directly, perhaps it makes sense to remove the "Printable" mode from MediaWiki?

T24256: Change printable link to JavaScript `print()`

I do know that the "printable" link, in the past had surprising amount of traffic for other websites. As in: without it, people don't know how to print (yes, i know, i know...)

So if we do remove the printable mode, then having the JS enabled print mode link is probably quite desirable I suspect.

I think T24256: Change printable link to JavaScript `print()` is definitely better than simply dropping the link entirely (although we'd have to hide it for no-JS). A feature is only useful if users know about it, and I think having the link exposes the fact that our pages look reasonably good when printed.