I'm not fully sure where to draw the line of IE support, It's in my opinion not useful to extend extra print hacks support for Internet Explorer <= 8 and deliver the hacks to all other browsers. But that would mean to kill more of the included rules.

Change 256619 had a related patch set uploaded (by VolkerE):
Align to CSS coding guidelines and fix CSSLint errors & warnings

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

Probably also taking into consideration enhanced page-break rules from https://en.wikipedia.org/wiki/User:GWicke/common.css

Citing @Esanders @Edokter from patch set comment https://gerrit.wikimedia.org/r/#/c/256619/1

For one, specificality should not be changed, as Umherirrender has already commented (inline). I also don't like '1pt', which *may* result in 0px in certain clients.

Comment updated shortly after reflecting next comment ;)

You mean @Edokter, not me :)

@Edokter Regarding your comments on using pixel unit values and not points:
Myself I have never experienced troubles with small point values when printing. I have been searching for articles on the matter and haven't found one yet* that supports the claim of 1pt disappearing on printed pages. As printers work with points that sounds odd. Would you point out some findings on this specific issue?

There has been questions answered around specifying [[ https://stackoverflow.com/questions/3186925/pt-or-px-for-specifying-border-width-for-print | border-width in px or pt for print ]] and around issues with thickness of printing lines (hairlines):

• Fractional numbers like 0.25pt are widely supported, just Chrome seems to eat up [[ https://stackoverflow.com/questions/3186925/pt-or-px-for-specifying-border-width-for-print#comment18631045_3187158 | values (back in 2012?) <= .8pt ]]
• Pixel units produce a different output for example on a 300dpi printer versus a 600dpi one in contrast to point units.

(*) References:

• https://stackoverflow.com/questions/9978335/specify-hairline-thickness-in-css-for-printing
• https://stackoverflow.com/questions/3186925/pt-or-px-for-specifying-border-width-for-print
• http://atirip.com/2013/09/22/yes-we-can-do-fraction-of-a-pixel/
• http://alistapart.com/article/goingtoprint/ Eric Meyer in 2002 using 1px borders without any explanation to its preference.
• http://css-discuss.incutio.com/wiki/Print_Stylesheets Jim Wilkinson in 2003 stating "to disagree with Zeldman's use of points for print, for the accessibility reasons given above" without clearly giving them.

@Edokter Second, regarding your concern on CSS specificity loss by exchanging for example div#jump-to-nav by #jump-to-nav and therefore erroneous display of non-printable items:
As it is a print-only stylesheet request no @media screen styles are loaded and therefore we don't have to overwrite with the same specificity. You can have a look at the styles included here:
view-source:https://en.wikipedia.org/w/index.php?title=Percent-encoding&printable=yes&debug=true

In view-source:https://en.wikipedia.org/w/load.php?debug=true&lang=en&modules=site&only=styles&skin=vector en:Wikipedia's MediaWiki:Common.css #content a.external.text:after, #content a.external.autonumber:after are assigned [[ https://developer.mozilla.org/en-US/docs/Web/CSS/word-wrap | word-wrap: break-word; ]] rule. We should add this to commonPrint.css

@TheDJ raised concerns in PS 6 over max-width: 100%:

This breaks inline images inside table layouts. (because 100% of as much as you 'need' == 0).
See also: T116318: Images in tables are too small

After some research, there are more issues connected to setting max-width:

• IE 8 makes img disappear in certain cases, also affects print stylesheets.
• It interferes with at least Google Maps.

Therefore I'm going to leave out the rule and scraping the original intent.

@Volker_E I think that is best for now, and that we should defer solving that problem to a later time.

Interestingly however, I recently spotted that WikiWand also has had some issues with this and thus also have made this particular max-width rule much more specific than most people would probably normally write it.

.image_wrapper:not(.linked_img_wrapper):not(.small_img_wrapper):not(.panoramic) .img_container>img {
    max-width: 100%;
}

Basically; thumbs only, but not if they are small, linked or wide.

@TheDJ Yes, I've thought about a more specific selector in the beginning. The question is then, in how many cases do we real make a difference to the better? With the more general rule, not being aware of the side effects found out later, that seemed reasonable. With a very specific rule that applies to very few wrong edge cases, maintainability and delivering it in core makes me feel opposing it without bugs raised or statistics…

Change 256619 merged by jenkins-bot:
Align to CSS coding guidelines and fix CSSLint errors & warnings

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