Page MenuHomePhabricator

Align commonPrint.css to (most) CSSLint errors&warnings and WMF's CSS Coding guidelines and cleanup
Closed, ResolvedPublic

Description

mediawiki.legacy/commonPrint.css needs an overhaul on coding style:

  • Coding guidelines: align colors
  • Coding guidelines: put every selector of combined selectors on one line
  • Coding guidelines: use border: 0 instead of border: none and put border shortcut structure into same order across selectors for better gzipping
  • Coding guidelines: whitespace in parenthesis
  • CSSLint: proof and fix overqualified selectors – followed-up in T136459 instead of here.
  • CSSLint: disable setting margin for inline elements
  • General: get rid of print style hacks f. IE 6&7?
  • General: give images max-width: 100% to stop them bleeding over the edge. See comment T120154#2003709
  • General: join pagination and 'Generic HTML elements'' rules
  • General: swap 1px border values with 1pt
  • General: add word-wrap: break-word to pre, .mw-code selector to aggressively wrap long words instead of going out of paper on those white space saved elements
  • General: add universal selector with filter and text-shadow resets to speed up printing. See comment at https://gerrit.wikimedia.org/r/#/c/256619/4/resources/src/mediawiki.legacy/commonPrint.css
  • General: we should carry over word-wrap: break-word for .mw-body a.external* links like it's done in en:Wikipedia's Common.css
  • General: do the list-style shorthand property right.

Event Timeline

Volker_E created this task.Dec 3 2015, 12:53 AM
Volker_E updated the task description. (Show Details)
Volker_E raised the priority of this task from to Lowest.
Volker_E claimed this task.
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptDec 3 2015, 12:53 AM
Volker_E renamed this task from Align and cleanup commonPrint.css to (most) CSSLint and WMF's CSS Coding guidelines to Align commonPrint.css to (most) CSSLint and WMF's CSS Coding guidelines and cleanup.Dec 3 2015, 12:54 AM
Volker_E set Security to None.

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.

Volker_E renamed this task from Align commonPrint.css to (most) CSSLint and WMF's CSS Coding guidelines and cleanup to Align commonPrint.css to (most) CSSLint errors&warnings and WMF's CSS Coding guidelines and cleanup.Dec 3 2015, 1:13 AM
Volker_E updated the task description. (Show Details)

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

Volker_E added a subscriber: Esanders.EditedDec 3 2015, 10:30 PM

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

Volker_E updated the task description. (Show Details)Dec 3 2015, 10:47 PM

@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 border-width in px or pt for print and around issues with thickness of printing lines (hairlines):

(*) References:

@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

Volker_E updated the task description. (Show Details)Dec 4 2015, 10:23 PM
Volker_E updated the task description. (Show Details)Dec 4 2015, 10:35 PM
Volker_E updated the task description. (Show Details)Dec 4 2015, 10:59 PM
Volker_E updated the task description. (Show Details)Dec 7 2015, 6:26 AM

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 word-wrap: break-word; rule. We should add this to commonPrint.css

TheDJ added a subscriber: TheDJ.Dec 7 2015, 10:34 AM
Volker_E updated the task description. (Show Details)Dec 20 2015, 6:47 AM
Volker_E updated the task description. (Show Details)Dec 28 2015, 4:12 PM

@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:

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

Volker_E updated the task description. (Show Details)Feb 5 2016, 8:59 PM
TheDJ added a comment.Feb 5 2016, 9:09 PM

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

Volker_E updated the task description. (Show Details)Feb 5 2016, 9:31 PM

@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…

This comment was removed by Edokter.

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

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

Volker_E updated the task description. (Show Details)