- From: NFSL2001 via GitHub <sysbot+gh@w3.org>
- Date: Tue, 27 Sep 2022 15:38:08 +0000
- To: public-css-archive@w3.org
@fireattack The Latin characters in Microsoft YaHei comes from Segoe UI (of Windows 7), just slightly enlarged. I don't think it looks terrible; in fact, comparing it to the original Segoe UI it is way more legible due to its increased font size. For the benefit of doubt, I have also tried out Traditional Chinese (Microsoft JhengHei) which also is based on Segoe UI. It did not make too much of a difference too. Both Chinese variants only had "issue" when using Windows 7 Classic theme. Following are attached screenshots from my Windows 7 work machine, with UI language English, Simplified Chinese and Traditional Chinese, all 3 presented using both Aero theme and Classic theme: <details> <summary>Expand for screenshot</summary> ## English ### Aero Evals to Segoe UI.  ### Classic Evals to Tahoma.  ## Simplified Chinese ### Aero Evals to Microsoft YaHei.  ### Classic Evals to SimSun.  ## Traditional Chinese ### Aero Evals to Microsoft JhengHei.  ### Classic Evals to PMingLiU.  </details> > GitHub, Bootstrap, Wikipedia, and later Stack Overflow, all had to roll back from using it due backslash from the community. Please note: most of these sites changes reference the only one "issue" regarding `system-ui`: https://infinnie.github.io/blog/2017/systemui.html on GitHub ([Bootstrap [note that the issue author is the same as the blog post author - conflict on interest]](https://github.com/twbs/bootstrap/issues/22328), [Wikipedia](https://phabricator.wikimedia.org/T175877#4776576)), which only "affects" Simplified Chinese, Classic theme, Windows 7 users. It should be in no way that such a minority group should be allowed to direct most of the users to stop using `system-ui` just because the font rendering is bad for their language in one old settings, ignoring all the other benefits of using `system-ui`. > Is it "intended"? Yes it is. But in the ideal world the intended use should give somewhat good result. It doesn't matter which end is causing the issue, at the end the website designer is the one who has to deal with it. Please note that what `system-ui` is *not* for giving good result, it is to **integrate with the look and feel of the native OS** (https://drafts.csswg.org/css-fonts-4/#system-ui-def). It is just faithfully reproducing what the user had already been using on their native OS, regardless of the font choice. If the designer doesn't like it, do stop using `system-ui`, but they're just missing on the chance to localize to the users correctly. > And keep in mind it is a "regression" in term of user experience. The current stack of `-apple-system,BlinkMacSystemFont,"Segoe UI",Helvetica,Arial,sans-serif,"Apple Color Emoji","Segoe UI Emoji"` can at least generate good result (Segoe UI) for these users (without sacrificing other users). Do note that this will make Windows 7 *Classic* theme (pointed in ["the issue"](https://infinnie.github.io/blog/2017/systemui.html)) display the wrong font: it should have been Tahoma, not Segoe UI. --- When I was in discussion with GitHub when they naively added Meiryo to the font stack (overriding Chinese text too), the devs have mentioned that they would very much like to use `system-ui`, [including if the user chose to use a serif font](https://github.com/primer/css/issues/1209#issuecomment-770645331), but is blocked only due to "the issue". Quote: >> Why prioritise system-ui over ui-sans-serif? If the system is using, say, a serif font as the system font, would Primer really want to use that? > > AFAIK, Primer tries to stay as close to the default system font as possible. So I would say yes. --- Mentioed in https://infinnie.github.io/blog/2017/systemui.html: > the `system-ui` font family evaluates to Microsoft YaHei UI, which, it turns out, not only lacks many font weights that Segoe UI has (say semibold), but has letters and numbers a little larger and bolder to match the Chinese text than what could have been designed with I acknowledge that this is an issue on Windows, but do note that this issue also affect other languages and system too. On Windows, Traditional Chinese uses Microsoft JhengHei, which has an even worse Bold weight compared to Simplified Chinese Microsoft YaHei. Both Chinese fonts come with 3 weight: Light, Regular, Bold. Following is a rough font weight comparison for both Chinese fonts (hanzi only) relative to Segoe UI (italic are new weights not in Windows 7):  Meiryo for Japanese isn't anywhere good; it only have 2 weights: Regular and Bold. On Mac side of things, the Chinese font PingFang comes in Simplified Chinese (China), Traditional Chinese (Taiwan), and Traditional Chinese (Hong Kong), each comes with 6 weights. However, the weights provided are ([source](https://support.apple.com/en-my/HT212587) [(2)](http://www.itfanr.cc/2020/12/23/pingfangsc-and-flutter-fontweight/)): 中文 | 英文 | FontWeight值 -- | -- | -- 苹方-简 极细体 | PingFangSC-Ultralight | w100 苹方-简 纤细体 | PingFangSC-Thin | w200 苹方-简 细体 | PingFangSC-Light | w300 苹方-简 常规体 | PingFangSC-Regular | w400 or normal 苹方-简 中黑体 | PingFangSC-Medium | w500 苹方-简 中粗体 | PingFangSC-Semibold | w600 Its Semibold isn't even reaching Bold weight of SF Pro. Only Japanese text is remotely good on Mac: Hiragino Sans comes with W0-W9, matching closely with SF Pro's weights. It's way better on Android (and some Linux) side: Noto Sans CJK comes with 7 weights, roughly matching Roboto's 6 weights. Also, all CJK regions uses the same font design, which is a plus when using `system-ui` since there is no discrepency between different localization. Point is, CJK fonts have been quite a pain on system vendors due to its pricey nature. "lacking many font weights" is definitely not a factor when considering a design to match user's system: there's only that many weights on all these OS, and OS fonts are limited to the same set of weights too. The burden of `system-ui` being "ugly" is on OS vendor on this issue. Website developers will be better off hard coding the best font for their own locale (which might be an issue; see next point) instead of relying on `system-ui` if they want a "good result". --- Also, there is additional benefits such as correctly localizing the font for the users, especially towards CJK users. Let me demonstrate: the following is a text typesetted in Microsoft YaHei (SC), Microsoft JhengHei (TC), Meiryo (JP):  Notice the following characters: `将`, `甩`, `复`, `与`, `窗`. These characters are written differently in different languages/regions due to an issue: [Han unification](https://en.wikipedia.org/wiki/Han_unification). By using `system-ui` and correct user localization settings (which most Chinese users do), this above issue is mitigated by using the correct font stack to display CJK Unified Ideographs, and preventing display of incorrect localization. Using `sans-serif` does not come with this benefit as it uses the *default* font fallback regardless of system locale settings, which on Windows prioritise Japanese over Chinese and leading to more issues than of broken Latin text. Hard-coding the font stack will only work if you're targeting one specific locale, as you will be required to order the priority of fonts. The locale settings in `system-ui` doesn't only help CJK, it might help with other locales too (e.g. [different italic forms of Cyrillic](https://russian.stackexchange.com/questions/1552/why-does-italic-%D1%82-look-like-m)). As I said, no reason to stop using `system-ui` for just some ugly display due to poor user (and system font) choice. *Ignore this point if your website has correct language tagging: `<html lang="zh-hans">`/`zh-hant`/`ja` will fix the font for `sans-serif` most of the time. If your (or user-generated) content does not have any language information, `system-ui` is the better bet for localization.* --- TL;DR: **The issue mentioned in https://infinnie.github.io/blog/2017/systemui.html is a non-issue as it isn't what `system-ui` tries to achive: providing the native OS feel that the user already had on their machine.** -- GitHub Notification of comment by NightFurySL2001 Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3658#issuecomment-1259687625 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 27 September 2022 15:38:11 UTC