Last modified: 2013-04-22 16:16:25 UTC
On a printable request, the screen stylesheets should not be rendered. However, if the screen type is a media query, it will be. This is because it is not taken into account by OutputPage::transformCssMedia. On a printable request OutputPage::transformCssMedia( 'screen and (min-width: 982px)' ) should return null, but the input is returned intact.
Fix at https://gerrit.wikimedia.org/r/#/c/43782/ needs review.
(In reply to comment #0) > On a printable request, the screen stylesheets should not be rendered. > However, if the screen type is a media query, it will be. > Can you elaborate on this? Are you saying browsers will apply a stylesheet wrapped in: > @media screen and (min-width: 982px) { .. } .. when printing? (In reply to comment #0) > OutputPage::transformCssMedia( 'screen and (min-width: 982px)' ) > > should return null, but the input is returned intact. How does this play with resources that are loaded from cache, generated by ResourceLoader from a neutral request context (namely load.php). There is no "printable" context in that, it can only be determined client side and/or by the browser.
Also, how (if) does this affect modules with stylesheets configured with just plain media=screen? I'm just looking for a more specific example of what this actually fixes? (what module's stylesheet is applied that should/will no longer?)
Sorry, I posted an example on https://gerrit.wikimedia.org/r/#/c/43117/ , since that's where you flagged the issue. I realize I should have posted it here too. Browsers will not apply screen stylesheets to print preview or the actual printout. However, like some other sites, we also have a printable view (e.g. https://en.wikipedia.org/w/index.php?title=1949_U.S._Open_%28golf%29&printable=yes ). This should apply only the print stylesheets, so you can see what it looks like without going to actual print preview. And it does, with one exception. If you have a screen media query like: 'screen and (min-width: 982px)' which we do for Vector's screen-hd, it incorrectly shows in printable view. This is the bug. load.php is actually not a neutral request context in terms of printable. That (printable=1 or printable=0) is explicitly passed in for this reason. On Wikipedia, the actual request with the issue is: https://bits.wikimedia.org/en.wikipedia.org/load.php?debug=false&lang=en&modules=ext.gadget.DRN-wizard%2CReferenceTooltips%2Ccharinsert%2Cteahouse%7Cext.wikihiero%7Cmediawiki.legacy.commonPrint%2Cshared%7Cmw.PopUpMediaTransform%7Cskins.vector&only=styles&printable=1&skin=vector&* It sets (among other things): div#footer { margin-left: 11em; padding: 1.25em; } which is from screen-hd.css. Without the gadgets (similar to what you might find on a test wiki), it's: https://bits.wikimedia.org/en.wikipedia.org/load.php?debug=false&lang=en&modules=skins.vector&only=styles&printable=1&skin=vector&* For context, you can compare to printable=0 below (the regular version) to see that the regular screen sheets are correctly excluded: https://bits.wikimedia.org/en.wikipedia.org/load.php?debug=false&lang=en&modules=skins.vector&only=styles&printable=0&skin=vector&* Either way, load.php calls ResourceLoader::respond, which calls ResourceLoader::tryRespondFromFileCache. However, printable requests are not cached, because ResourceFileCache::useFileCache returns false since printable is not a recognized key. (Side note, if printable requests were cached, it would need to be added to ResourceLoaderContext::getHash). Non-printable requests are of course cached, and this does nothing to change caching. It does not affect regular 'screen' stylesheets, and I included tests that should verify. Let me know if I can clarify.
https://gerrit.wikimedia.org/r/#/c/43782/ is merged.
