Page MenuHomePhabricator

Skin Minerva Neue: do not manually assign fonts
Closed, DeclinedPublic

Description

Currently, skin Minerva Neue (default skin for mobile) assigns

-apple-system, 'BlinkMacSystemFont', 'Segoe UI', 'Roboto', 'Lato', 'Helvetica', 'Arial', sans-serif;

as fonts for paragraphs. (Source code.)

This is suboptimal because it does not allow user to display the content in their preferred sans-serif fonts in settings.

In contrast, the desktop version of most Wikimedia sites (using skin Vector) only has "sans-serif" configured, so it will use whatever sans-serif font users choose in their browser or system settings.

One particular example I want to mention is reading mobile Wikipedia on Windows. Because of how the rule is set, it will use "Segoe UI" (instead of something like Arial, as most of browsers default to), which is not very optimal for article reading.

Event Timeline

It seems to be changed in T175877.

While I fully agree that we should "gives preference to system typeface", I'm not sure what's the reasoning to not just use sans-serif.

Shouldn't it be enough to fall to whatever the system default font would be? Why do we need to specify fonts like "Segoe UI" or Roboto? it will actually cause to not use system typeface under certain circumstances, for example, if someone installed 'Segoe UI' on Android. And as mentioned before, while "Segoe UI" is the default UI font for Windows, it is not meant to be used in text paragraphs other than UI elements - after all it is suffixed with "UI" for a reason.

@fireattack You've already pointed out the originating task T175877. sans-serif provides suboptimal reading experience, specifically on mobile platforms. The task gives all the details. Segoe UI was not developed solely for user-interface chrome, but also for reading materials.
You are still able to set your default font in your profile's common.css to your personal preference.

Edit: revised

sans-serif provides suboptimal reading experience

I didn't see any mention about this in T175877, could you elaborate?

Keep in mind what we had before was not just sans-serif. Most of the references listed there also talk about moving from something like Helvetica, Arial, Sans-serif to what similar to we have today, but none of them seem to talk about why mere sans-serif would not be enough.

It looks to me (on Android) if you assign sans-serif, it would just fall back to Roboto. I would guess it would be similar on iOS or MacOS.

After all, simply using sans-serif is the choice of Wikipedia (desktop site) for at least 10 years, so I'd imagine it wouldn't be terribly wrong.

Segoe UI was not developed solely for user-interface chrome, but also for reading materials.

Thanks for the information.

Reverting to platform default font would not be the best experience in many cases. The solution to this will / would be to provide a font-chooser where users can select from a few options, one of which is "Platform default". Maybe, as feature request that can be considered.

More details about "Reverting to platform default font would not be the best experience in many cases" would be appreciated.

Like I said before, I read task T175877, as well as all the articles about font stack in the references.

The main goal of such "font stack" seems to be "use system fonts as much as possible, because they're better", which I totally agree.

However, the part I don't understand is why the practice seems to be exactly the opposite of the goal.
Instead of let browsers use default fonts (which is either system fonts, or user configured), the stack hard-codes a few fonts (albeit being system fonts in certain OS).

In most of cases it makes no difference, of course; but in some cases, for example if someone is using non-Windows system, but have manually installed Segoe UI on his/her OS, then the CSS rule will result in showing the content in Segoe UI, NOT the system font.

If the rule is simply sans-serif, it won't be affected by what fonts he/she has installed; and the user himself can adjust his browser setting to have a consistent look and feel for any website that doesn't force a font.

I am not an expert on font like you guys and I fully respect your hard work and expertise. I just didn't find an explanation on why such font stack is better than simply "sans-serif" (the emoji part, I can understand), and I honestly didn't see any talk about it in task T175877 or any of the references. Additionally, if it's so good, why Vector skin (on desktop) hasn't adopted it yet.

Again, I'm fully willing to change my opinion or view if new evidence/knowledge is presented.

Tl;dr: I've made a task to satisfy the need for using system default fonts with some easy-to-access preferences. I believe that approach is feasible, but reverting to the default for all users is not the direction the developers have taken in the last years:
T244748: Add client-side skin preferences drop-down

Imho what one perceives as the "better" font is subjective. I personally find Arial ('sans-serif' on Windows) was a good option 20 years ago, but now it's terrible compared to modern fonts. It was designed with CRT monitors in mind before font anti-aliasing was a thing. The current fonts used are more legible (see the criteria here) and pleasant, I believe that to be the deciding factor to use these.

See the design guideline for some rationale, however I'm not aware of the detailed history of how these choices were made. There was some research and experimentation with different fonts throughout the years, this is the stack that's the result as of today. There are some pieces of the history in the linked task if you want to learn about it.

Note that the purpose in Minerva is NOT to use the system default (which is merely a fallback), but to use fonts with similar features on 3 major platforms: Win, Mac, Lin. On Mac, iPhone it tries to use 'San Francisco', on GNU+Linux 'Liberation Sans'. Probably it will use the system default only on Android (Roboto font).
Also, Segoe is licensed to MS, thus it is not expected that it would be installed on GNU+Linux or Mac. Distros certainly can't do that for legal reasons.

As a general answer to your task: I think user viewing preferences is the solution to cater to all user needs.
For your personal, immediate experience, you can use Vector or MonoBook skins (I assume you are not on mobile, if Segoe is the problem for you),
or add one line to your global.css or common.css to reset body { font-family: sans-serif; }.

Regarding the font: imho Segoe UI (part of Windows since Vista) is a better option than Arial, but I would even go further and use Noto (or Roboto) font.

The main goal of such "font stack" seems to be "use system fonts as much as possible, because they're better", which I totally agree.
However, the part I don't understand is why the practice seems to be exactly the opposite of the goal.
Instead of let browsers use default fonts (which is either system fonts, or user configured), the stack hard-codes a few fonts (albeit being system fonts in certain OS).

See also https://www.mediawiki.org/wiki/Design/Projects/Improve_mobile_reading_experience

Thanks for taking time to reply, really appreciate it.

Note that the purpose in Minerva is NOT to use the system default ... On Mac, iPhone it tries to use 'San Francisco'

This is surprising. I thought it is would be the same as Android. I assume it would end up with Helvetica then. Thanks for letting me know.

Also a side note: I don't actually think Arial is better than Segoe UI, Arial just happened to be the default fallback of "sans-serif" on Windows for historical reasons, like you said.

The reason I prefer 'san-serif' in CSS rule is more because this way, you can set up your preferred font in your browsers, and it works across any websites if they don't assign fonts.
I'd admit this is more relevant on desktop as you can't really easily config fonts on most of mobile browsers.

Anyway, I think I can see the rationale now: we want to show the content in system fonts: the new, updated ones like San Francisco on Mac; however, the browsers still default to Arial/Helvetica after all these years, which is not ideal.

At this point I started to feel the whole thing should be changed on browser side (why are they still default to these outdated fonts to begin with? Especially considering most of the OS don't use them as default UI fonts any more), but that's another story. At least Android is kinda of on the right track I guess..

Thanks for taking time to reply, really appreciate it.

You're welcome.

At this point I started to feel the whole thing should be changed on browser side

You can also use a font changer addon, like https://chrome.google.com/webstore/detail/font-changer-with-google/jgjhhoglgjdklldfgoffdiaceffijeke or similar.

The main goal of such "font stack" seems to be "use system fonts as much as possible, because they're better", which I totally agree.

However, the part I don't understand is why the practice seems to be exactly the opposite of the goal.
Instead of let browsers use default fonts (which is either system fonts, or user configured), the stack hard-codes a few fonts (albeit being system fonts in certain OS).

Thanks for your question, @fireattack.
We're in fact opinionated on using certain fonts over others before falling back to sans-serif. Point in case is, that browser vendors are not necessarily follow a standard. For example, Firefox on macOS assigns sans-serif to 'Helvetica', while Safari and Chrome default it to 'Helvetica Neue' which provides a much better readability. We've even filed a task to Mozilla about it ('s side effects).

In most of cases it makes no difference, of course; but in some cases, for example if someone is using non-Windows system, but have manually installed Segoe UI on his/her OS, then the CSS rule will result in showing the content in Segoe UI, NOT the system font.

That's a benefit – or a problem depending of your point of view – of user-system relying font stacks. We have to assume that users who install those fonts are advanced users and be able to accept such experience or go for personal customizations in places like MediaWiki:Common.css
There are certain blurred edge case areas where we are out of control, that's the beauty and power of the web. But with MediaWiki:Common.css we are still enabling users to go for their own choices on top of the majority of users being presented with Wikimedia design supported font choices.

Volker_E triaged this task as Lowest priority.Feb 10 2020, 9:09 PM

@Volker_E as I've written to @fireattack, I don't think this task would ever be implemented. Maybe it can be closed to clarify that?
@fireattack If the answers to your questions are satisfactory can this task be closed?
I note that a possible solution to the problem raised can be included in T91201: [EPIC] Accessibility settings/preferences