In T73240#5806993, @Jdlrobson wrote:

Since Vector will be frozen (at least on the short term) as part of the desktop improvements project. I think now is a good time to discuss typography for the new version of Vector.
Let's discuss that here https://www.mediawiki.org/wiki/Talk:Reading/Web/Desktop_Improvements#Will_there_be_any_changes_to_typography? and be proactive this time rather than reactive.

@AronManning Please be aware, that Wikimedia Design team has already come up with font recommendations in the Design Style Guide for better legibility on HiDPI screens and it is in use on MobileFrontend/Minerva Neue skin already.

Removing Timeless as Desktop Improvements project's working field is Vector only.

Change 570074 had a related patch set uploaded (by Aron Manning; owner: Aron Manning):
[mediawiki/skins/Timeless@master] Font update: use 'Noto Serif' for the content, 'Lora' (serif) for headings, 'Poppins' (sans) for the logo-text.

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

I've been spending some time in the last months to try different fonts, most notably Noto and Roboto, out of a few dozen fonts I've considered.
I've found Noto Serif to be the most legible, which I've been using continuously for 2 months and also a few users of my theme for some time. For Latin scripts, I'm confident to suggest using it as the default font in possibly all actively maintained skins. For scripts that I don't know, I hope there will be people interested in testing it.

For headings, I've found the Lora font for its elegance, for only the logo-text the Poppins font (specimen, which resembles the font in the Wikimedia logo with more balanced proportions.
These are subjective choices with a small impact and quite a few possible alternatives.

For monospaced I've included 2 new options: Hack (sample) and Source Code Pro (see Specimens). Hack is a free font specifically for source code. It's not on the wmf fontcdn, yet.

See fonts-README.md for a description of current and proposed fonts.

@Volker_E thanks for the link, I was looking exactly for that style guide. It suggests using the Noto family for "great coverage of languages". Charter (more correctly Charis SIL) is not available as a web-font, Lato is a fallback to Noto Sans in this patch (which assumes there will be a user setting to choose sans fonts). The OS-specific monospaced fonts are also included as fallbacks to the 2 platform-neutral fonts specifically designed for source code.

I'm looking forward to hearing feedback from interested testers. The fonts can be tested with

• userstyle (download: addon, userstyle),
• or using the custom theme which also resets the font-size in Timeless from 95% - 15.2px (typical) to the default 100% - 16px. For reference: Vector font-size is 87.5% - 14px.
• or by downloading the patch in skins/Timeless: git review -d 570074

Change 570245 had a related patch set uploaded (by Aron Manning; owner: Aron Manning):
[mediawiki/skins/MonoBook@master] Use Roboto (sans) font

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

The above patch set is for testing Roboto (sans) with MonoBook, small font (font-size: 79.375% -> 12.7px).

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

Just curious, is there a particular reason to deviate from the fonts used in the style guide? It would make more sense to adopt the Wikimedia styles that is also used on Minerva and native apps instead of picking other fonts for UI standardizations and many reasons.

In T243508#5857329, @alistair3149 wrote:

Just curious, is there a particular reason to deviate from the fonts used in the style guide? It would make more sense to adopt the Wikimedia styles that is also used on Minerva and native apps instead of picking other fonts for UI standardizations and many reasons.

The proposed font is actually suggested by the guide. I propose rethinking the primarily used fonts and font-sizes because these choices were made a long time ago and the available fonts became more polished since that time. This question needs to be revisited ca. every decade and this is a good time to do it.

Tl;dr: I've taken the useful fonts from the guide and added a few more for specific use-cases. The font I suggest to use as primary is actually proposed by the style guide: "The Noto family provides great coverage of languages, providing good alternatives for both serif and sans-serif typefaces."

Noto stands for "No more tofu" (squares instead of characters that are missing from the available fonts). Its aim is to cover all languages, as such, it is a perfect match for the multilingual nature of Wikimedia.

The guide also suggests using a few platform-specific sans-serif and monospaced fonts, which were tested in Minerva. These fonts are kept as fallbacks in this proposal in case the primary webfont is not available. Platform-specific fonts, however, are either inconsistent between platforms, or outdated: Arial (used by Vector) has compatible alternatives, but its legibility is far behind modern options. The guide has no suggestion at all for platform-specific serif fonts.

Minerva and Timeless currently use 'Segoe UI' (on Windows) for article content and 'Times New Roman' / 'Georgia' respectively for headings. The rest of the skins use platform defaults (Arial), CologneBlue (abandoned) being an exception with 'Verdana'. Both Noto and Roboto offer better readability and a more polished, professional impression.

The guide also suggests 3 platform-neutral fonts (1 serif, 1 sans and 1 both):

• 'Charis SIL' (or its predecessor 'Charter') aren't available as webfonts and I'm not sure it's 100% free licensed.
• I found 'Lato' (sans) to be just another font, with indistinguishable "I" and "l" and some inconsistent spacing.
• I've said enough good words about the 'Noto' family.

None of these 3 are used in the skins and I would suggest deprecating Charis SIL and Lato for the above reasons.

The best option from the guide is Noto. This was the original Android font that was replaced by Roboto in Android 4.0. Roboto and Noto are both widely used and very high-quality in terms of legibility (even at small sizes), anti-aliasing, they are clean and pleasing to look at. My impression is that Roboto - designed specifically for mobile-screens - is even more legible at small sizes than Noto, therefore I've added it as the proposed primary for <16px font sizes, while also proposing to bump Vector's 14px font-size to 16px: displays are much higher resolution than in 2010 when Vector's font-size was decided.

I've also collected the platform-specific serif and monospaced fonts from the skins, adding 3 platform-neutral fonts that are likely to be available on technical-minded people's systems. These benefit those, who work a lot with .css, .js, and templates.

The fonts chosen for headings have a smaller impact, thus I went with the font that I found most elegant with sufficient coverage while searching for fonts. The guide only has Lato and Charter as an option in this category. I've found Lora, Poppins, and Overpass to be cleaner alternatives. This is, of course, an opinionated choice: many fonts could be chosen.

The Wikimedia Design team has also, in collaboration with product owners and performance team decided, that we can't and won't provide web fonts on large scale projects for now, as the negative performance & user experience impact isn't worth the investment.

@AronManning The typography that the style guide suggested is not adopted at all by Vector, I suggest that instead of focusing on font choices first, we need to focus on adopting the hierarchy (size, styles, weight, etc.) defined in the style guide as it is more suited for modern day screens. Adopting the hierarchy first will improve the readability issues across different platforms, and also builds a foundation for studying other font choices.

As for the font choices, the guide suggests using platform-specific fonts because of performance concerns. By using fonts already available in an OS, clients can avoid loading the web font needed thus saving bandwidth, that is especially crucial for clients with slower connections and limited data. If performance is no longer a concern or we are using a check for connection speed, then using a platform-neutral webfont would be the way to go.

• Charis SIL (modern version of Charter): It is available as a webfont and it is 100% free licensed with an OFL license. That's one of the reason it was picked in the first place.
• Noto: While Noto is known for its wide support for different languages, no language extensions have adopted Noto yet. It might be better to take this to the Universal Language Selector team and check if they are planning to use Noto. If they are not planning to do so, there is no clear advantage of using Noto.
• Roboto: Widely adopted as the system font of Android. On top of what you mentioned, Roboto is used alongside with Noto often and has a high compatibility with other Noto fonts. It would also save bandwidth on Android and ChromeOS devices as they don't have to download the webfont to use the page. The downside of Roboto is that it has less "friendly" than Lato as there are less curves and more crowded.
• Lato: Known for having great readability on different screens, it is also a widely adopted font on the web. It has more curves, and warmer compared to Roboto. As for the inconsistent spacing you mentioned, do you have specific examples of it?

Before deciding on anything, we need more insight from the Wikimedia Design Team on why they picked those choices, and the research behind it.
@Volker_E would you mind to share those information?

@Volker_E if web fonts are out of the picture for now, I suggest that we should focus on updating the hierarchy on the current Vector skin first to match with the style guide to improve readability. However, it might introduce a lot of problems with existing templates or layout hack uses on WMF sites.

Is there any input from the Desktop Improvement Team regarding the task?

In T243508#5857963, @alistair3149 wrote:

@AronManning The typography that the style guide suggested is not adopted at all by Vector, I suggest that instead of focusing on font choices first, we need to focus on adopting the hierarchy (size, styles, weight, etc.) defined in the style guide as it is more suited for modern day screens. Adopting the hierarchy first will improve the readability issues across different platforms, and also builds a foundation for studying other font choices.

Sure, go ahead with it. I've made a few adjustments in my theme too. At the moment my focus is on the font, that would be a really big improvement for the readers' experience. Those issues you mention are parallel to it and less impactful, so there's no point in waiting for that. The two can be done in parallel.

As for the font choices, the guide suggests using platform-specific fonts because of performance concerns.

I have to learn about those performance measurements. Could you give some links?
The industry has solved any performance issues that might arise from webfonts, as practically every up-to-date website - big or small - uses webfonts nowadays. We should follow suit.

By using fonts already available in an OS, clients can avoid loading the web font needed thus saving bandwidth, that is especially crucial for clients with slower connections and limited data.
If performance is no longer a concern or we are using a check for connection speed, then using a platform-neutral webfont would be the way to go.

I know about that aspect. It's easy to remove that one line - on slow connections - which imports the declaration of the webfonts, thus removing the performance impact, where it matters. The client will fall back to the platform-specific fonts, which will give a 100% functional experience even if not the latest and greatest typography.
As with modern and not-modern browsers, we should distinguish between the two use cases and choose the best (in terms of UX) solution where the technical background makes it possible.

Also note, that the webfont loading will be asynchronous and the first draw (before the fonts are cached) will happen with the system fonts without delay. The client can detect if loading takes long and disable webfonts, but usually by the second page load the fonts are cached and no longer a performance concern.

• Charis SIL (modern version of Charter): It is available as a webfont

Thanks for the link. What I meant is it's not available on any webfont cdns, not even the wmf fontcdn which is very odd, given that it is the suggested font. I cannot demo its use in skins without uploading it into the skin, so this is a big minus for me.

• Noto: While Noto is known for its wide support for different languages, no language extensions have adopted Noto yet. It might be better to take this to the Universal Language Selector team and check if they are planning to use Noto. If they are not planning to do so, there is no clear advantage of using Noto.

I see the advantage of using Noto in the improved UX. I don't understand how that would depend on the Language Selector team. Would you explain it?

• Roboto: Widely adopted as the system font of Android. On top of what you mentioned, Roboto is used alongside with Noto often and has a high compatibility with other Noto fonts. It would also save bandwidth on Android and ChromeOS devices as they don't have to download the webfont to use the page. The downside of Roboto is that it has less "friendly" than Lato as there are less curves and more crowded.

Roboto is a very good option and Roboto Slab (serif) also satisfies the friendliness (readability) aspect. I am actually undecided between Noto Serif and Roboto Slab, therefore I've submitted patches to demonstrate both in the different skins.
For <16px I prefer Roboto, both Slab serif and sans. I'd use the serif variant for the default skin and the sans variant for the nostalgic skin MonoBook.
At 16px I'm undecided between the two. Because of their compatibility, I suggested using Noto as a fallback for Roboto (also suggested by Google), if not using Noto as the default.
In Timeless I would definitely use Noto as that skin has a more smooth and elegant style.

• Lato: Known for having great readability on different screens, it is also a widely adopted font on the web. It has more curves, and warmer compared to Roboto. As for the inconsistent spacing you mentioned, do you have specific examples of it?

Try these "words": InItIalIze InlInIng InIcIolonIsed Look at the big 'I' and compare it to 'm'-'o'-'n'-'o' in monotonic.
I've also read good reviews about Lato, but my experience did not justify those. Anyway, there are more elegant, cleaner fonts.

Before deciding on anything, we need more insight from the Wikimedia Design Team on why they picked those choices and the research behind it.

Indeed. That's the purpose of this quasi-RfC.
To clarify again: The choices I've presented are what I believe atm to be very good choices, much better than the current options. However, there is no best option, many different fonts could be chosen and all would work well in many cases.
The choice for headings is particularly opinionated. Legibility in big blocks and wide coverage are not a concern there, as there's a feasible fallback (Roboto or Noto).
I would be happy to see other proposals and do a comparison with those.
It would be helpful for skin designers to have a list - maybe a long list - of fonts that can be chosen to give character to a skin, while having a solid common choice for the body of the text.

I have to learn about those performance measurements. Could you give some links?

As @Volker_E mentioned, WMF decided to not provide web fonts for large scale projects for now as the trade off on performance and UX is not worth the investment. When a website uses a webfont, the client needs to make a HTTP request then download the font, it is an additional delay on the critical rendering path. Take Roboto as an example, the WOFF2 (most compressed format) for Roboto Regular (400) with basic latin is 16KB. Plus the latency introduced in the HTTP request, it could easily be 2-3 seconds load delay on a slow 3G network. Page load time can be solved with font-display:swap or lazyload, but that will introduce other UX issues such as font popping when web font is loaded. For a site like Wikipedia that serves a lot of people with slower and capped connections, the negative performance impact is significant.

The industry has solved any performance issues that might arise from webfonts, as practically every up-to-date website - big or small - uses webfonts nowadays. We should follow suit.

The industry has improved a lot upon webfont with introducing compressed format such as WOFF2, use of CDN, etc. However, WMF is in a unique situation as they need to serve a lot of people across the world, and it is unlikely to adopt a third-party solution regarding webfonts. Self-hosting on CDN would be the only appropriate solution. And as Volker_E mentioned above, that it wouldn't be considered for now.

I know about that aspect. It's easy to remove that one line - on slow connections - which imports the declaration of the webfonts, thus removing the performance impact, where it matters. The client will fall back to the platform-specific fonts, which will give a 100% functional experience even if not the latest and greatest typography.

That approach would require an additional script such as the Font Loading API to detect connection type as I mentioned, which is also additional performance overhead but would be an interesting concept to experiment with.

I see the advantage of using Noto in the improved UX. I don't understand how that would depend on the Language Selector team. Would you explain it?

The font used for different languages are defined and provided by the ULS team if I am not mistaken. Since the advantage of using Noto is to maintain consistency across different languages, it would help if the ULS team is planning to adopt Noto.

Roboto is a very good option and Roboto Slab (serif) also satisfies the friendliness (readability) aspect.

To clarify, I meant friendliness as the feel of the font. Lato is less boxy than Roboto and has more curves, which gives it a warmer feeling.

Try these "words": InItIalIze InlInIng InIcIolonIsed Look at the big 'I' and compare it to 'm'-'o'-'n'-'o' in monotonic.

I've also read good reviews about Lato, but my experience did not justify those. Anyway, there are more elegant, cleaner fonts.

Personally I find Lato has better readability compared to Roboto as the alphabets are more distinguishable. It would be beneficial if we can set up am A/B testing with a larger sample size to determine which font has better readability.

I would strongly suggest that we wait for the insights from the Wikimedia Design Team or conduct our own research before proceeding on the issue. Any research that they had done would be very helpful and could override what has been done.

In T243508#5858838, @alistair3149 wrote:

I have to learn about those performance measurements. Could you give some links?

As @Volker_E mentioned, WMF decided to not provide web fonts for large scale projects for now

I hope VolkerE will link to the reasoning: I'm not familiar with the wmf's infrastructure and find it hard to imagine the causes. The standard industry practice shows that webfonts are a feasible solution. For how long is "for now"?

the WOFF2 (most compressed format) for Roboto Regular (400) with basic latin is 16KB. Plus the latency introduced in the HTTP request, it could easily be 2-3 seconds load delay on a slow 3G network.

We are shipping 55.7 KiB (14 KiB compressed) css required for the first draw and 631.4 KiB (177.3 KiB compressed) async javascript with the first response. 16 K and the extra roundtrip can indeed double the time to first draw, but only on the first load. Is it worth to sacrifice cross-platform consistency and better UX for those few seconds one time? Maybe it's not even necessary. The first load can happen with a platform font without extra delay, or we can wait a few seconds for the font to load, then fall back to platform font or the font popping, or we can simply allow the font to pop on the first load. I notice the latter (font pop) on many websites. It's weird, but after a the second page-load it's not there anymore, so I forget about it.

The industry has improved a lot upon webfont with introducing compressed format such as WOFF2, use of CDN, etc. However, WMF is in a unique situation as they need to serve a lot of people across the world, and it is unlikely to adopt a third-party solution regarding webfonts. Self-hosting on CDN would be the only appropriate solution. And as Volker_E mentioned above, that it wouldn't be considered for now.

It already exists: https://tools.wmflabs.org/fontcdn/
Whether that would cope with the load from all readers: I assume yes, that's the point of a cdn. It's static files that are cheap and simple to distribute, replicate and cache client-side. The performance of the cdn can be tested by gradually enabling webfonts on the smaller, then the big wikis.

I know about that aspect. It's easy to remove that one line - on slow connections - which imports the declaration of the webfonts, thus removing the performance impact, where it matters. The client will fall back to the platform-specific fonts, which will give a 100% functional experience even if not the latest and greatest typography.

That approach would require an additional script such as the Font Loading API to detect connection type as I mentioned, which is also additional performance overhead but would be an interesting concept to experiment with.

Thanks for the link. Connection type info is not necessary. A short javascript (ca. <1 KiB) can wait a second and disable font loading (remove the font-face stylesheet) if it's still not loaded. No need for polyfill: https://caniuse.com/#feat=font-loading. The only browser that lacks support is... IE11, where I would simply go with the reflow (font pop). It only happens on the first load, so it's not worth more investment.

Hmm I do not appear to have that problem. Make sure that you are using Lato 2.0 instead of the old 1.0 version on Google Fonts.
What's your browser configuration and did you use any kerning or ligature in your stylesheet?

I've just pulled Lato from the wmf fontcdn, which is basically a mirror of google fontcdn afaict, so Lato 1.0. Your waterfall with Lato 2.0 looks better, but "I" and "l" are still indistinguishable. The spacing inconsistency seems to be fixed. To consider Lato 2 or Charis SIL, these must be on the fontcdn as that's the only way to get the fonts to the clients. We can't ask the readers to "please, install this font...".

I would strongly suggest that we wait for the insights from the Wikimedia Design Team or conduct our own research before proceeding on the issue.

My intent with this RfC was to get the Design Team involved with established research practices and documents of previous research that I couldn't find. This proposal is the result of few months subjective research I've been doing, so I'd like to make this more systematic, include different scripts and contributors with different language backgrounds.

Change 570638 had a related patch set uploaded (by Aron Manning; owner: Aron Manning):
[mediawiki/skins/Vector@master] Unify @ff-* (was: @font-family-*) variables among skins.

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

Change 570074 had a related patch set uploaded (by Aron Manning; owner: Aron Manning):
[mediawiki/skins/Timeless@master] [TEST] Font update: use Lato (sans) for the content, Lora (serif) for headings. Load the necessary fonts from the wmflabs fontcdn.

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

Change 570277 had a related patch set uploaded (by Aron Manning; owner: Aron Manning):
[mediawiki/skins/Timeless@master] [TEST] Font update: host 2 fonts in the skin

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

Change 572456 had a related patch set uploaded (by Aron Manning; owner: Aron Manning):
[mediawiki/skins/MonoBook@master] [TEST] Font update: use Lato (sans) for the content. Load the necessary fonts from the wmflabs fontcdn.

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

Change 572456 had a related patch set uploaded (by Aron Manning; owner: Aron Manning):
[mediawiki/skins/MonoBook@master] [POC] Font update: use Lato (sans) for the content. Load the necessary fonts from the wmflabs fontcdn.

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

Change 570639 abandoned by Jdlrobson:
[POC] Font update: use Lato (sans), Lora (serif) fonts for consistent look on all platforms

Reason:
No changes to typography are planned in the near future so I'm removing this from the review queue. The link to this will continue to be preserved on T243508 if we decide to pick this up in future.

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

Change 570277 abandoned by Isarra:
[mediawiki/skins/Timeless@master] [POC] Font update: host 2 fonts in the skin

Reason:

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

Change 570074 abandoned by Isarra:
[mediawiki/skins/Timeless@master] [TEST] Font update: use Lato (sans) for the content, Lora (serif) for headings. Load the necessary fonts from the wmflabs fontcdn.

Reason:

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

Change 572456 abandoned by Aklapper:
[mediawiki/skins/MonoBook@master] [TEST] Font update: use Lato (sans) for the content. Load the necessary fonts from the wmflabs fontcdn.

Reason:

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