Change 570597 had a related patch set uploaded (by Aron Manning; owner: Aron Manning):
[mediawiki/core@master] Unify @font-* variables among skins. Import font stack from 'mediawiki.ui/fonts.less'.

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

Change 570619 had a related patch set uploaded (by Aron Manning; owner: Aron Manning):
[mediawiki/skins/MonoBook@master] Unify @font-* variables among skins. Import font stack from 'mediawiki.ui/fonts.less'.

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

Change 570638 had a related patch set uploaded (by Aron Manning; owner: Aron Manning):
[mediawiki/skins/Vector@master] Unify @font-* variables among skins. Import font stack from 'mediawiki.ui/fonts.less'. This commit does not change the default article font (system's default sans-serif font), but changes headings to the serif stack, only using fonts available on the client system.

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

Change 570639 had a related patch set uploaded (by Aron Manning; owner: Aron Manning):
[mediawiki/skins/Vector@master] TEST: Import Roboto webfonts for consistent look on all platforms. This is only for the purpose of testing. For production the @font-face stylesheets need to be loaded asynchronously from html: @import blocks page drawing until the stylesheet is loaded.

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

Skins are for catering different user wants and needs and personal preferences. I still don't see how unifying the font choice provides reasonable value to these needs?

Per what Volker said, I find it very unlikely that users would want this on MonoBook, for example. That skin is all about not changing things from defaults unless there's a very good reason.

I'm also a bit wary of the proposed sizes, even without getting into the fonts themselves - what's the justification behind them? How would they be relating, proportionally, to the width of the content itself? Given different skins have very different content layouts, how would making font sizes the same work with that?

In T244425#5857792, @Volker_E wrote:

Skins are for catering different user wants and needs and personal preferences. I still don't see how unifying the font choice provides reasonable value to these needs?

I've renamed the task to make it more clear. I thought the css declarations speak for themselves.

The basic font-stack used by Timeless and Minerva is quite similar. The rest don't have a font stack, presumably the new Vector will have.
The set of fonts between Timeless and Minerva is redundant and inconsistent at the same time. Both skins try to achieve the same target: good coverage and consistency. As it is now, there is a duplication of efforts.

The stacks for the 3 purposes - serif, sans-serif, monospaced - can be unified and moved to core, so for ex. Timeless would benefit from the font choices for Mac explored by Minerva devs.
Ultimately the benefit will be for the new Vector.

These stacks don't define the default fonts, only 3 sets for sans, serif and monospaced. This gives the skins an easy choice to apply any set of these with the possibility to prepend the preferred (custom) font(s) or even ignore the common set.
This won't limit the options for skins, but rather make it easier to choose different sets that are already tested on many systems.

In T244425#5857871, @Isarra wrote:

I find it very unlikely that users would want this on MonoBook, for example.

I want to ask them, so I made the patches to demonstrate it.

That skin is all about not changing things from defaults unless there's a very good reason.

Readability is a good reason. On the other hand, if people are used to it then that does not matter. To know which one is more prominent I have to ask the actual users. Yesterday I made a poll about font-size, for example.

I'm also a bit wary of the proposed sizes, even without getting into the fonts themselves - what's the justification behind them? How would they be relating, proportionally, to the width of the content itself? Given different skins have very different content layouts, how would making font sizes the same work with that?

To avoid any misunderstanding I only proposed changing Timeless 15.2px -> 16px and the new Vector 14px -> 16px.
Minerva is already 16px, MonoBook is good as it is, Modern is bad as it is.

16 px (100% - initial) font-size is a sweet spot for font rendering. The 0.8px saving in Timeless is not worth the loss in legibility. Vector should be updated to this decade. Display resolutions increased significantly in a decade.
The best solution would be to make a font-size selector (ex. 14-15-16-18-20px), like discord has, in which case 16px is the most reasonable default.

At this point these are proposals that I hope people will test with the submitted patches to see what impression they get.
In my experience the layouts change very little and I see no reason to be worried about that. The few cases where icons or textfields get misaligned, I've probably already fixed in my theme to layout properly dynamically, adapting to any font size. I'll submit the necessary patches for those layout problems.

Change 570757 had a related patch set uploaded (by Aron Manning; owner: Aron Manning):
[mediawiki/skins/MinervaNeue@master] Unify @ff-* (was: @font-family-*) variables among skins. Import font stack from 'mediawiki.fonts.less'.

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

The patches titled "Unify @ff-* (was: @font-family-*) variables among skins." are ready for review:

core -- This patch includes definition of the common system font stacks and verbose documentation of the fonts. Does nothing in itself, skins have to opt in.

Vector, MinervaNeue, MonoBook -- These patches leave the article and heading fonts intact while unifying the font variables. The monospaced font stack is extended to include popular coder fonts (if installed to the client system).

Timeless -- This patch includes a merged font stack from Minerva and Timeless, most notably 2 fixes for iPhones/Macs. The heading font (serif) is changed from 'Times New Roman' to Georgia on Windows. The logo-text font is changed from 'Times New Roman' to bold Verdana (sans) on Windows. The monospaced font stack is extended.

The "Font update:" patches are for testing the proposed fonts:
Vector with Roboto font (14px) for content and Lora (serif) for headings
Timeless with 'Noto Serif' font (16px) for the content and Lora (serif) for headings
MonoBook with Roboto font (12.7px)

The set of fonts between Timeless and Minerva is redundant and inconsistent at the same time.

Why is this problematic? Skins are expected to be inconsistent - they provide completely different experiences.
If you wanted you can create a ComicSansSkin :)

FWIW MinervaNeue's long term goal is to make use of https://github.com/wikimedia/wikimedia-ui-base/blob/master/wikimedia-ui-base.less as a dependency which is blocked on T123359 so renaming variables in Minerva to variables seems counterproductive to that goal.

In T244425#5863184, @Jdlrobson wrote:

The set of fonts between Timeless and Minerva is redundant and inconsistent at the same time.

Why is this problematic? Skins are expected to be inconsistent - they provide completely different experiences.

Because for ex. the font fixes for specific version iPhones in Minerva are not used by Timeless. If we were to enable Timeless on mobile, it should include that fix.
I believe skins are expected to be consistent in this regard while being different in meaningful ways, not in the bugs.

However, having a different font stack when the purpose is the same is not meaningful. Such inconsistencies just lead to confusion and duplication of effort. If a skin wants to deviate from the standard font stack, it can, but none of the skins do that at the moment: Timeless and Minerva use almost the same fonts, the rest uses the default. Skins can continue using the default Arial, even if there is a suggested common font stack, that's not the concern of that patch.

If you wanted you can create a ComicSansSkin :)

Duplicate a whole skin just to change the font? I'd prefer Extension:Theme.

FWIW MinervaNeue's long term goal is to make use of https://github.com/wikimedia/wikimedia-ui-base/blob/master/wikimedia-ui-base.less as a dependency which is blocked on T123359 so renaming variables in Minerva to variables seems counterproductive to that goal.

I was confused about how 'wikimedia-ui' and 'mediawiki.ui' relates to each other. According to this comment the latter is deprecated, I wasn't sure about the former. It seemed to be in the wrong place in the 'oojs' folder - and importing is not solved since 2017 -, so I wasn't going to use it. Maybe copying that file into the 'mediawiki.less' folder would solve that issue, or a 'wikimedia-ui' folder that's added to the importPaths. I can't find those "*importPaths". Where should I look? T140807: Remove $wgResourceLoaderLESSImportPaths

To be consistent with 'wikimedia-ui': naming the fonts file as "wikimedia-ui-fonts.less" would be acceptable? Then the import will be: @import 'wikimedia-ui-fonts' and once importing 'wikimedia-ui-base.less' is figured out, presumably @import 'wikimedia-ui will import both the '-base' and the '-fonts'.
The last point about the variable names: what matters is that the names are consistent. What the names are exactly is a decision to be made. Following @Volker_E's comment I've renamed the variables to Emmet-style abbreviated according to the coding conventions.
This solves the issue in development that searching for the css rule 'font-family' would return more false positives than good results and it's also more compact. The only drawback being that a new developer won't get it at the first blink, only after seeing its use in a 'font-family' rule. I find the benefits significantly outweigh the drawback.

Tl;dr: Is merging the font stack declarations with 'wikimedia-ui' and keeping the Emmet-style abbreviated names an acceptable solution?

In T244425#5863184, @Jdlrobson wrote:

FWIW MinervaNeue's long term goal is to make use of https://github.com/wikimedia/wikimedia-ui-base/blob/master/wikimedia-ui-base.less as a dependency which is blocked on T123359 so renaming variables in Minerva to variables seems counterproductive to that goal.

The file has been renamed to 'wikimedia-ui-fonts.less' to follow that pattern. Any time the importing is resolved in T123359, this file can be moved into 'wikimedia-ui-base'. It's proper place would be in the wikimedia-ui-base project, extending upon the former definitions copied from Minerva.
The system font-stack variables have been renamed from ff-sans-system, etc. to @ff-system-sans, @ff-system-serif, @ff-system-mono - more consistent with wikimedia-ui-base's declarations, while keeping the abbreviated form.

I've also removed 'Helvetica Neue', which was removed from Minerva, but forgotten in Timeless. This is the kind of inconsistency that unifying the declarations removes. I've noticed that by pure chance, @Volker_E it would have helped to mention that.

Related tasks:
T175877: Update sans-serif font stack on mobile web to use system typefaces
T221043: Apply operating system font stack to MinervaNeue monospace elements

@Demian Please stop adding such tasks as subtasks, that's historically incorrect and confusing to contributors in and outside of the Foundation. Your requests here and the tasks added by you are not inherently connected, it provides wrong paths to retracing them.

In T244425#5863236, @Demian wrote:

In T244425#5863184, @Jdlrobson wrote:

The set of fonts between Timeless and Minerva is redundant and inconsistent at the same time.

Why is this problematic? Skins are expected to be inconsistent - they provide completely different experiences.

Because for ex. the font fixes for specific version iPhones in Minerva are not used by Timeless. If we were to enable Timeless on mobile, it should include that fix.
I believe skins are expected to be consistent in this regard while being different in meaningful ways, not in the bugs.

That's up to the skin authors to decide. MinervaNeue and Vector are the currently maintained skins by Wikimedia Foundation, for historic, community outreach and technical reasons we've decided not to change Vectors sans-serif font choice to WikimediaUI Base's yet.
Timeless is a volunteer-driven skin, with its own ideas and design choices.
MonoBook doesn't receive any such changes any more, as it's a testing, maintenance and communication investment, that we as non-profit have to be very careful about and choose wisely and we've decided not to invest in such changes to MonoBook if no clear bug is caused by its status quo.
Compare https://www.mediawiki.org/wiki/Talk:Typography_refresh to see how complex and side-effect loaden a font choice can be.

Skin authors on the other hand can already use WikimediaUI Base as their starting point and rely on the generalized variables and font recommendations.

In T244425#5866108, @Volker_E wrote:

the tasks added by you are not inherently connected

I've moved the tasks to "Prior art" section in the task description.

The aspect of this proposal is too extensive. I'm breaking it up into bite-sized tasks where individual, practical questions can be discussed without confusion.

In T244425#5866173, @Volker_E wrote:

Compare https://www.mediawiki.org/wiki/Talk:Typography_refresh to see how complex and side-effect loaden a font choice can be.

I understand the complexity of choosing fonts, that's why I started this task with extensive documentation of what I could find about the current stack and the reasons and decisions that led to it.
Unfortunately, it's hard to find documentation of those decisions and the discussions are scattered. Thanks for linking Talk:Typography_refresh, I'll reference it from the documentation.

I reckon there are questions on that talk page from years ago, that are unanswered. Are there some more discussions, where tidbits can be found?

@Volker_E please see my question above: Is there any more relevant discussions regarding the fonts included and left out from the font-stacks?

To the renaming variables part here, please see https://www.mediawiki.org/wiki/Manual:Coding_conventions/CSS#Variable_naming convention.

In T244425#5878689, @Volker_E wrote:

To the renaming variables part here, please see https://www.mediawiki.org/wiki/Manual:Coding_conventions/CSS#Variable_naming convention.

https://gerrit.wikimedia.org/r/c/mediawiki/skins/Vector/+/570638#message-768e4015c26348b53115e8645a593a85fd8daf83

Change 570597 abandoned by Aron Manning:
Unify @ff-* (was: @font-family-*) variables among skins. To import in skins: @import 'wikimedia-ui-fonts'.

Reason:
Working on a different approach

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

Change 570277 abandoned by Aron Manning:
Font update: TEST adding Hack (monospaced) @font-face declarations.

Reason:
Out-of-scope, experimental

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

Change 570245 abandoned by Aron Manning:
Font update: TEST using Roboto (sans) font. @import the necessary @font-face declarations from the wmflabs fontcdn.

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

We are not considering any font changes via the Desktop Improvements project. That would be a massive research project to do again, and we cannot do that simultaneously with the already known workload. With that in mind, we are going to untag Desktop Improvements from these tasks.

In T244425#5885502, @Quiddity wrote:

We are not considering any font changes via the Desktop Improvements project. That would be a massive research project to do again

Thank you for the feedback. What I've learned about the 2014 Typography refresh project while working on this task, pointed into this direction. I'd finish documenting (referencing) the decisions made at that time as I've started in T244790 and leave this task for the future and for community input if that's possible. I'd assume the wmf will revisit this question sometime in the future (that might mean years) and well-placed, organized documentation will inform future contributors.

I don't see the font update happening in the context of Desktop Improvements as I've indicated in the task description and on-wiki, still, it was worth learning about the previous project. I see this only feasible as an option for the user, that would be best presented with the Universal Language Selector's font chooser, which already has the necessary framework implemented.

However, the ULS's font option is very well hidden and placing it in a viewing settings pop-up (T91201) would be more accessible. I wonder if implementing that pop-up is considered in the context of the Desktop Improvements project.
Note that the fonts available in ULS are not a question for Desktop Improvements.

Change 570277 restored by Aron Manning:
Font update: TEST adding Hack (monospaced) @font-face declarations.

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

Change 570245 restored by Aron Manning:
Font update: TEST using Roboto (sans) font. @import the necessary @font-face declarations from the wmflabs fontcdn.

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

Change 570597 restored by Aron Manning:
Unify @ff-* (was: @font-family-*) variables among skins. To import in skins: @import 'wikimedia-ui-fonts'.

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