Page MenuHomePhabricator

Logos that aren’t 135px wide don’t scale correctly at 1.5x and 2x resolutions
Open, Needs TriagePublic


MediaWiki recommends that the $wgLogo is 135px wide, but does not enforce this, and even in Wikimedia production there’s a wide variety of actual sizes, ranging from 90px (trwikiquote) to 157px (arbcom_enwiki, though overridden there via common.css). However, HD logos assume that base width, and don’t scale correctly if the 1x logo has a different width. The following CSS rule is hard-coded in ResourceLoaderSkinModule::getStyles():

background-size: 135px auto;

If the 1x logo is less wide than 135px, then the logo will become larger than it should when you zoom from 140% to 150%; if it’s wider than 135px, the logo will not become as large as it should, or even shrink at that zoom threshold. (That’s in Firefox, at least – Chromium has different zoom steps, and in the transition from 125% to 150% the change isn’t as visible.)

This command, run in operations/mediawiki-config.git, finds all the logos that have a nonstandard width and also a 2x variant:

find static/images/project-logos/ -type f -name '*.png' -\( -not -\( -name '*-1.5x.png' -or -name '*-2x.png' \) \) -exec identify {} + 2>/dev/null |
    awk '$3 !~ /^135x/' |
    grep -Ff<(find static/images/project-logos/ -type f -name '*-2x.png' | sed 's/-2x\.png/.png/') |
    awk '{ print $3, $1 }' |
    sort -n

The current output can be found at P9040; kbdwiki is one example where the logo jumps up in size as you zoom from 140% to 150%, whereas on wikidatawiki, it shrinks somewhat (see T230120#5464541 for screenshots). Another significant example is pawikisource, where the HD logo even gets clipped:

I believe T203822: Consider adding .mw-wiki-logo {background-size: 135px} to skin CSS would be one way to solve this problem, though wikis would probably not be happy if their existing logos change in displayed size.

Event Timeline

Restricted Application added subscribers: Liuxinyu970226, Aklapper. · View Herald TranscriptSep 4 2019, 5:27 PM
Isarra added a subscriber: Isarra.Sep 5 2019, 5:41 PM

So the reason for the 135px thing on the higher-resolution versions is because raster background images really aren't intended to scale properly for different viewports.

If you want an image to scale properly to HiDPI, you need to either use <img> tags with a srcset for a raster, or use an SVG. In content, even svgs are rendered into pngs so that users get consistent display (installed fonts are the same, still works on older browsers, applies translations properly, whatever), so it's all <img> tags with srcsets set for different resolutions. In the interface, we use SVGs for icons, and only fall back to pngs for older browsers as necessary.

The core logo handling, however, uses a background image, but most logos used are rasters ($wgLogo and $wgLogoHD are the common config options, though $wgLogoSVG or some such does exist). Unfortunately background images just scale as they are even at higher resolutions for backwards compatibility - it's assumed that if you want it at these higher resolutions, you will specifically set the background-size to contain or to whatever the actual desired size is, and use a larger image, or, preferably, simply use an svg from the start (as we do with the rest of the interface). We work around this for the logo by setting the HD versions of the logo as the new background at breakpoints using @media queries, but this also requires manually setting the background size, and as you've noticed, logo sizes vary wildly. But since we don't know what the background size is (and there's really no way to find out in mw, either, as $wgLogo etc take a url path to set as a background, and php needs an internal path to get file information, which even if it is on the same server will still going be totally different), we basically just guess. Hence the 135px.

Isarra added a comment.Sep 5 2019, 5:56 PM

There is also a major issue in that a 'recommended size' isn't something we can meaningfully standardise, as what is going to be optimal is also going to vary considerably depending on a site's (main) skin. 135px is a good size for MonoBook. 155px is a better size for Vector (while still almost fitting on MonoBook, which tops out at ~154x155px). Timeless starts looking a bit weird when you go under 150px, and if anything the recommended there would be more like 160px. Greystuff and BlueSky use the same logo, but then scale it down to 66px and 55px respectively, and we don't even need a HiDPI version for that at all.

Isarra added a subscriber: ashley.Sep 5 2019, 6:11 PM
Isarra added a comment.Sep 5 2019, 7:14 PM

In Timeless we basically just threw out the entire thing to roll a new logo handler using img srcsets (and optionally, the core thumb handler to generate the different resolutions for us) - this allows for arbitrarily-sized images to scale correctly regardless of how big they are to begin with.

We may want to consider moving core in this direction. Even using svgs as a scaling logo won't properly cover our usage, as many sites may still just not have a proper svg version of their logo, or it may exist, but at a larger filesize than the raster would be, which is also an issue.

Linked image size:

  • 1x: 18.24 KB
  • 2x: 51.75 KB
  • svg: 229 KB
TheDJ added a subscriber: TheDJ.Sep 6 2019, 1:06 PM
Izno moved this task from Backlog to Change CSS on the CSS board.Jan 2 2020, 4:19 PM