Repository navigation
Do not let system-ui come before "Segoe UI" in font-family—or remove it from the font stack altogether #22328
Description
Reverting #21356.
See https://infinnie.github.io/blog/2017/systemui.html for the reason.
Reacted by Federico Zivolo and Tom Lutzenberger
Reacted by Mr Beedell, Roke Julian Lockhart
Activity
mdo commentedon Apr 7, 2017
We ran into some issues with this in GitHub, too. Will push an update.
bardiharborow commentedon Apr 19, 2017
Is there an upstream bug with the Chrome team, or is this just entirely unfixable?
infinnie commentedon Apr 19, 2017
@bardiharborow I believe it an unwanted feature.
patrickhlauke commentedon Apr 19, 2017
It does seems that the feature itself - that with
system-uithe 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 commentedon Apr 19, 2017
@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 commentedon Apr 19, 2017
/cc @patrickkettner
patrickkettner commentedon Apr 19, 2017
thanks for the headsup @patrickhlauke - will pass over to the font folks
alanhogan commentedon May 15, 2017
I haven't seen any screenshots of
system-uicausing 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.Does anyone have relevant screen shots to share?
@mdo, does GitHub localize their interface? that is, would GitHub ever render in e.g. Chinese instead of English?
patrickkettner commentedon May 15, 2017
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 commentedon May 15, 2017
Fascinating. Thanks for following up, @patrickkettner!
alanhogan commentedon May 16, 2017
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-weight500or lower to render in400, and600or higher to render in700under 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 commentedon May 16, 2017
bardiharborow commentedon Aug 3, 2017
Is someone able to remind me why
BlinkMacSystemFontisn't also affected by this? Additionally, would re-addingsystem-uiafter"Segoe UI"fix this issue?patrickkettner commentedon Aug 3, 2017
Do you mean why isn't
BlinkMacSystemFontaffected by the issue in windows?yep, as per the bug title
bardiharborow commentedon Aug 3, 2017
@patrickkettner, sorry, I've just realised how stupid a question that is, given it's BlinkMacSystemFont.
I might look into re-adding it in a later version then.
patrickkettner commentedon Aug 3, 2017
@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 commentedon Aug 4, 2017
@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 commentedon Aug 4, 2017
@infinnie great! with full text weight options?
infinnie commentedon Aug 4, 2017
@patrickkettner not so for some non-Latin scripts.
patrickkettner commentedon Aug 4, 2017
sure, I meant whatever
BlinkMacSystemFontis aliased to (which I believe is . SF NS Display/.SF NS Text, no?)