Do not let system-ui come before "Segoe UI" in font-family—or remove it from the font stack altogether

[infinnie]

Reverting #21356.

See https://infinnie.github.io/blog/2017/systemui.html for the reason.

[mdo]

We ran into some issues with this in GitHub, too. Will push an update.

[bardiharborow]

Is there an upstream bug with the Chrome team, or is this just entirely unfixable?

[infinnie]

@bardiharborow I believe it an unwanted feature.

[patrickhlauke]

It does seems that the feature itself - that with system-ui the browser uses the default defined by the system - is actually working exactly as it should, so not a bug in Chrome itself. the problem lies with the OS' choice of system font. e.g. looking at the screenshot on https://infinnie.github.io/blog/2017/systemui.html i would say that Chrome here behaves exactly as instructed - "use the system font".

in short, i don't believe this needs an upstream bug for Chrome, since it's behaving correctly. the fact that this then leads to sites that look horrid/broken when the system font is horrid/broken is purely a Bootstrap issue.

[bardiharborow]

@patrickhlauke I was about to ask if Windows had a correct fallback algorithm when dealing with English text in UI, but then I realised that the whole point of switching the OS language is that the OS is fully localised to Chinese, so this may not be something that exists. As an alternative, is there a bug lodged with Microsoft to fix the font (though good luck getting any progress with that). I notice that even Chrome is using the broken font for it's UI (omnibar, etc.), so I don't know if they would consider implementing a platform-specific fallback for this situation (though Chrome seems like they might be stubborn on the issue to try to force Microsoft into acting instead). Failing all that, we may just have to wait 6 months and see.

[patrickhlauke]

/cc @patrickkettner

[patrickkettner]

thanks for the headsup @patrickhlauke - will pass over to the font folks

[alanhogan]

I haven't seen any screenshots of system-ui causing unwanted effects on OSes newer than Windows Server 2008, although I read infinnie’s blog post mentioning font-weight issues on Windows 8.1 and/or 10.

1. Does anyone have relevant screen shots to share?

2. @mdo, does GitHub localize their interface? that is, would GitHub ever render in e.g. Chinese instead of English?

[patrickkettner]

This is the same text rendered in SegoeUI and YaHei, with default weights.

The big issue is when you start trying to use multiple weight variants. They simply aren't there for a lot of non english glyphs

Top is arial (I don't have segoe install on this computer), bottom is YaHei. YaHei renders the same for all weights.

I don't know for a fact if they localize, but I set my preferred language to Chinese, loaded up UC Browser, and opened a proxy via Tianjin, and Github still rendered in English. It seems unlikely they localize if they don't pick up on any of those browser hints.

[alanhogan]

Fascinating. Thanks for following up, @patrickkettner!

[alanhogan]

You know, it's surprising to me that Arial in normal font-weight seems to have rendered in bold. AFAIK Arial usually or only (?) ever comes in bold (700) and normal (400), so the "thin" weight is presumably actually 400. I’d expect everything requested to display in font-weight 500 or lower to render in 400, and 600 or higher to render in 700 under font-weight fallback rules.

Of course I am not letting this distract from the core take-away that YaHei only has one weight of Latin letters available.

Just wondering if there is also something funky going on with font-weight rules such that even core assumptions can be shaken.

[patrickkettner]

Honestly more likely I just beefed the demo

On May 16, 2017, at 10:46 AM, Alan Hogan notifications@github.com wrote:

You know, it's surprising to me that Arial in normal font-weight seems to have rendered in bold. AFAIK Arial usually or only (?) ever comes in bold (700) and normal (400), so the "thin" weight is presumably actually 400. I’d expect everything requested to display in font-weight 500 or lower to render in 400, and 600 or higher to render in 700 under normal fallback rules.

Of course I am not letting this distract from the core take-away that YaHei only has one weight of Latin letters available.

Just wondering if there is also something funky going on with font-weight rules such that even core assumptions can be shaken.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[bardiharborow]

Is someone able to remind me why BlinkMacSystemFont isn't also affected by this? Additionally, would re-adding system-uiafter "Segoe UI" fix this issue?

[patrickkettner]

Do you mean why isn't BlinkMacSystemFont affected by the issue in windows?

Additionally, would re-adding system-uiafter "Segoe UI" fix this issue?

yep, as per the bug title

[bardiharborow]

@patrickkettner, sorry, I've just realised how stupid a question that is, given it's BlinkMacSystemFont.

yep, as per the bug title

I might look into re-adding it in a later version then.

[patrickkettner]

@bardiharborow not a stupid question at all! I really hope I didn't make you feel like it was. Just wanted to make sure I understood it correctly. And for what its worth, the same issue may very well exist. There is a much larger windows presence in non latin-character based countries, so there are more eyes on it there. If you have the ability to install a non english version of os x (preferably an older one), check and see what latin text renders like there.

[infinnie]

@patrickkettner macOS in non-Latin-script-based languages still uses .SF NS Display/.SF NS Text as the primary UI typeface, which then fall backs to the default font of the current locale.

[patrickkettner]

@infinnie great! with full text weight options?

[infinnie]

@patrickkettner not so for some non-Latin scripts.

[patrickkettner]

sure, I meant whatever BlinkMacSystemFont is aliased to (which I believe is . SF NS Display/.SF NS Text, no?)