ResourceLoader does not process media queries for printable view with JS-added CSS
OpenPublic

Description

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.


Version: 1.22.0
Severity: normal

bzimport added a subscriber: Unknown Object (MLST).
bzimport set Reference to bz49722.
Mattflaschen created this task.Via LegacyJun 17 2013, 11:13 PM
gerritbot added a comment.Via ConduitJun 18 2013, 1:42 AM

Related URL: https://gerrit.wikimedia.org/r/69276 (Gerrit Change I691588c39da7fadeac1ca2ace2c1b769fc4e1bd6)

Krinkle added a comment.Via ConduitJun 18 2013, 2:45 AM

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

Mattflaschen added a comment.Via ConduitJun 18 2013, 4:54 AM

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

gerritbot added a comment.Via ConduitFeb 25 2014, 9:39 AM

Change 69276 abandoned by Krinkle:
ResourceLoader: Pass printable parameter to load.php.

Reason:
Closing for now.

https://gerrit.wikimedia.org/r/69276

Mattflaschen added a comment.Via ConduitFeb 25 2014, 11:45 PM

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).
Krinkle moved this task to Triaged on the MediaWiki-ResourceLoader workboard.Via WebApr 28 2015, 6:45 PM
Krinkle added a comment.Via WebMay 31 2015, 10:14 PM

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

matmarex added a subscriber: matmarex.Via WebMay 31 2015, 10:49 PM

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

TheDJ added a subscriber: TheDJ.Via WebJun 1 2015, 1:24 PM

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.

Mattflaschen added a comment.Via WebJun 3 2015, 3:33 AM

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.

Add Comment