Page MenuHomePhabricator

[EPIC] Various parts of MediaWiki don't respect default browser font size
Open, Needs TriagePublic

Description

Parent task: T363845: [EPIC] Typography scale and font sizing

Having started with T312933 and T312970 related to WikiEditor (2010), I discovered that quite many MediaWiki parts and extensions don't respect the default browser font size, setting an absolute font-size in px instead of relative in em/rem. I'm not sure whether I should create an individual task for every finding because there's quite a few of them, their list is likely to grow, and they are typical.

Here's what I stumbled upon as of now:

image.png (366×737 px, 179 KB)
image.png (454×1 px, 62 KB)
image.png (254×262 px, 12 KB)
image.png (345×240 px, 27 KB)
image.png (339×204 px, 8 KB)
* Page-Previews have a fixed font-size of 14px. Here's how they look in Firefox with 20px as the default font size. The width of the popup in various orientations is also fixed (450px, 320px).Diffs are rigidly set to 13px. That's their look.#siteSub is strictly 12.8px. Here's how it looks like.line-height in .sidebar-toc is exactly 18px. It may be not obvious what's so bad but here's the difference with 16px as the default size.padding-left of subsections on the same screenshot is 8px (IMHO, difficult to see even with standard settings).

According to some research, more than 3% of users have non-default browser font size.

Related task: T27257: Don't specify font-size in pixels for accessibility

Hardcoded font-size audit

The following query in codesearch identified font-sizes set in px (font-size:.*px;) in Wikimedia maintained repos:
https://codesearch.wmcloud.org/deployed/?q=font-size%3A.*px%3B&files=.less&excludeFiles=&repos=

Wikimedia deployed extensions/projects

Wikimedia deployed skins

Open questions

  • How should icons scale with different font sizes? (follow up work for T365731 )

Related Objects

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes
Jdlrobson subscribed.

We are handling the desktop improvements part of this in T261334

Results of T363845 should help point the way for this issue. An audit of hardcoded font sizes wouldn't hurt as pre-work for the implementation. It's something we'll probably have to do anyways eventually.

I think this ticket can remain open as a tracking or epic, but various fixes should be handled separately with dedicated tickets, so that the teams responsible for maintaining the repos are made aware of the changes, and potential regressions are easier to track.

The fixes for these issues are very much in line with T363845, and should consist of replacing the hard coded values with Codex design tokens. The font-sizes for these token are now in rem's, yay! I actually think this makes the changes safer than if the values were in ems.

Regarding an audit of these hardcoded sizes, the following codesearch query identifies px values in Less files, in Wikimedia maintained repos: https://codesearch.wmcloud.org/deployed/?q=font-size%3A.*px%3B&files=.less&excludeFiles=&repos=
There seems to be a fair bit in Popups, so I'll create a task for that, but for this ticket, I'm removing the web-team tag as the issue spans multiple teams, and I'll paste the results of that query into the task description.

Jdrewniak updated the task description. (Show Details)
Jdrewniak subscribed.
Jdlrobson renamed this task from Various parts of MediaWiki don't respect default browser font size to [EPIC] Various parts of MediaWiki don't respect default browser font size.May 28 2024, 10:01 PM
Jdlrobson moved this task from Incoming to Epics/Goals on the Web-Team-Backlog-Archived board.
Jdlrobson added subscribers: DTorsani-WMF, CCiufo-WMF.

@DTorsani-WMF @CCiufo-WMF we believe you've done a lot of work in this area. Not sure if you already have an epic that this can be merged into?

We believe since this ticket was filed a lot has changed, so it might be beneficial to create a new ticket reframing the problem.

We think it would make sense for the epic to live in the design system team backlog and any subtasks that need web team to make changes filed as sub tasks in our own backlog. Does that make sense?

This is related to T363845: [EPIC] Typography scale and font sizing, but not really the same thing. My understanding is that this task is about identifying and fixing hardcoded font sizes, where T363845 is about creating an internally consistent typography scale and font sizing within Codex and the skins. This is a worthy effort and we can keep it in our backlog, but it would not be a priority for the Design System Team any time soon.

The typography scale and font-sizing could come first in the best of all possible worlds, in the second best, we would just go for em or rem based sizing with IE11 out now to remove this backwards accessibility failures from our interface and replace the rem(/em) values with the scale being in place and tested rightfully in big products.

Change #1112873 had a related patch set uploaded (by VolkerE; author: VolkerE):

[mediawiki/core@master] mediawiki.content.json.less: Replace pixel font-size value for relative

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

Change #1112873 merged by jenkins-bot:

[mediawiki/core@master] mediawiki.content.json: Replace pixel font-size value for relative

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

On the Web team we've made some progress in this area by adopting Codex tokens (which have rem font-sizes now). So I reran this query, expecting there to be less results than in the task description, but to my surprise, there are actually more! This is partially due to the fact that the query scan only .less files and not .css files. A lot of new results come from MediaWiki-extensions-Translate, which recently converted css files to less.

In https://phabricator.wikimedia.org/T27257#7095502 @Volker_E mentions that the wikimedia-stylelint now checks for px font-sizes, but it looks like many extensions are running older versions of that.

it looks like many extensions are running older versions of that

nvm! It looks like 0.18.0 is the latest version, and the vast majority of extensions are using that!

Removing MonoBook as this seems to have been a false positive from comment mentions of pxs.

Change #1117313 had a related patch set uploaded (by VolkerE; author: VolkerE):

[mediawiki/core@master] mediawiki.debug: Replace pixel font-size value for relative ones

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

Change #1117313 merged by jenkins-bot:

[mediawiki/core@master] mediawiki.debug: Replace pixel font-size value for relative ones

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

Change #1117660 had a related patch set uploaded (by VolkerE; author: VolkerE):

[mediawiki/core@master] mediawiki.diff: Replace pixel font-size value for relative one

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

Change #1117660 merged by jenkins-bot:

[mediawiki/core@master] mediawiki.diff: Replace pixel font-size value for relative one

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

Volker_E updated the task description. (Show Details)

Change #1118059 had a related patch set uploaded (by VolkerE; author: VolkerE):

[mediawiki/core@master] mediawiki.editfont: Replace pixel font-size for relative unit one

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

Change #1118059 merged by jenkins-bot:

[mediawiki/core@master] mediawiki.editfont: Replace pixel font-size for relative unit one

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

Tagging Codex Steering Committee as Codex Steering Committee superseded Design-System-Team in 07/2025 and as this open lingering Design-System-Team task has no other active codebase- or team-type project tags and otherwise would not show up on any active workboards otherwise