Page MenuHomePhabricator

Skins should use wordmark and icon keys instead of 1x, 2x and svg wgLogos keys
Open, Needs TriagePublic

Description

MediaWiki recommends that the $wgLogos['1x'] 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:

Plan

  • All deployed Wikimedia sites will provide an SVG for wgLogos['icon']
  • Going forward we will move away from the 1x,2x and svg logos. Notably the existing skins that make use of 1x e.g vector classic, Monobook, Timeless will stop using them, instead making use of the icon, wordmark, tagline instead.
  • All 1x, svg and 2x definitions will be removed.

Event Timeline

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.

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.

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
Jdlrobson added a subscriber: Jdlrobson.

It's my understanding that we are moving away from 2x and embracing svgs for logos.

In the new Vector, img tags are used rather than CSS
en.wikipedia.org?useskinversion=2

With this in mind I dont think we need to do anything here other than recommend the usage of svgs.

Please feel free to reopen if im overlooking something.

You appear to be overlooking that this affects svg logos too, and is actually worse there because the 135px assumption hits all resolutions, instead of just >1ppp, when using those.

In the new Vector, img tags are used rather than CSS
en.wikipedia.org?useskinversion=2

Timeless also rolls its own logo handling, in part due to the faulty assumptions of this module, but I would argue this is precisely why we need to be fixing the core methods and modules to better support the needs of the skins and users. Every skin wandering off and doing their own thing is basically the worst possible outcome in terms of providing consistent results for end users and easily made and maintainable code for developers.

Although I'm not really sure why the svgs need a size specification to begin with? The svgs should just be the correct nominal size themselves...

Timeless also rolls its own logo handling, in part due to the faulty assumptions of this module,

What are the faulty assumptions? What is needed in core for Timeless to remove that handling?

would argue this is precisely why we need to be fixing the core methods and modules to better support the needs of the skins and users

Concretely, what fixes do you recommend?

So I dunno if I was even complaining about the right things here, but there's basically two issues with the sizing/scaling for hidpi/svgs, mostly boiling down to them not being square:

  • Nominal widths of logos fitting in a 130-160px square logo area can vary wildly; assuming 135px wide can mess up both larger width ones (making them just too small) and especially smaller, taller ones (making them too large and then get cut off at top and bottom), so really we should just be telling mw the logo size/width like we do with wordmark images unless they're just squares and it doesn't really matter (skin can set whatever is appropriate instead)
  • Logos are generally non-square due to combining wordmark and image logo into a single image; we should really be encouraging actually square logos somehow, maybe just by breaking this up as standard. (Skins like old vector, monobook, etc would then be able to just stack the logo and wordmark on top of each other, and skins like new vector, timeless, etc can do other things with them consistently with the same files)

we should really be encouraging actually square logos somehow, maybe just by breaking this up as standard

And if that's what you were going for already then just go ahead and disregard everything I've been rambling about and how do we actually use it and migrate it for everything...?

And if that's what you were going for already then just go ahead and disregard everything I've been rambling about and how do we actually use it and migrate it for everything...?

Going forward, I imagine support for the 1x logo is going to dwindle as we move towards the wordmark and icon logos and encouraging new skins to use those. I question the value of continuing to invest in this particular form of logo, particularly when it can be achieved for many projects using stacked wordmark, icon and tagline components like so:

<a href="/wiki/Main_Page"style="text-align: center;">
		<img class="mw-logo-icon" src="/static/images/mobile/copyright/wikipedia.png" alt="" aria-hidden="true" style="height: 100px;width: 100px;" width="50" height="50">
		<span class="mw-logo-container">
			<img class="mw-logo-wordmark" alt="Wikipedia" src="/static/images/mobile/copyright/wikipedia-wordmark-en.svg" width="119" height="18">
			<img class="mw-logo-tagline" alt="The Free Encyclopedia" src="/static/images/mobile/copyright/wikipedia-tagline-en.svg" width="117" height="13">
		</span>
	</a>

Note: For Wikipedia and other wikis we still need to convert the icon to an SVG, but going forward its assumed that will always be an SVG square.

For wikis that just want to use a logo without a wordmark e.g. https://en.wikivoyage.org/wiki/Main_Page?useskinversion=1 they would just use the new icon property but it would need to be an SVG and square.

Does that make sense?

Jdlrobson renamed this task from Logos that aren’t 135px wide don’t scale correctly at 1.5x and 2x resolutions to Replace the 1x, 2x and svg wgLogos keys.Thu, Mar 25, 5:42 PM
Jdlrobson renamed this task from Replace the 1x, 2x and svg wgLogos keys to Skins should use wordmark and icon keys instead of 1x, 2x and svg wgLogos keys.
Jdlrobson updated the task description. (Show Details)
Jdlrobson edited projects, added Timeless; removed CologneBlue.

I've held off on a proof of concept patch for MonoBook for the time being since the WMF config was just nowhere near there yet in terms of having the logos/wordmarks consistently available for all the sites, but once that's a little closer, we should absolutely get on migrating this. (WikiVoyage is a great example why we can't just do it now, though, as some may actually want only a notext logo and thus will only set that, and some do want a wordmark but just don't have one, presently...)

GreyStuff also has an example sidebar-style portrait logo built out of these in the footer too now, if icons are available and enabled at all.

T273250 is also going to pose a problem here for any sites using png notext icons. (Mostly wikipedia, I think?)

Technically Timeless has already switched over, just has the old logos as a fallback. Also needs to deprecate its own custom handling, but that's a separate problem entirely...