- From: Dominik Röttsches via GitHub <sysbot+gh@w3.org>
- Date: Mon, 12 Mar 2018 10:00:58 +0000
- To: public-css-archive@w3.org
I would prefer not to introduce an additional property. I think the best way to address this is to specify at least one font known to have coverage to avoid going into system fallback for variation selectors plus improvements to browsers following the [Cluster Matching](https://drafts.csswg.org/css-fonts/#cluster-matching) rules more closely. While Chrome does take the whole grapheme cluster into account for font-fallback, for variation selectors our shaping library considers a grapheme successfully shaped if `b` is found, already in the "first pass", i.e. before doing one fallback pass to find a full `b + c1` suitable glyph. I agree that this should be improved to follow the Cluster Matching rules, filed [Chromium issue 820929](https://bugs.chromium.org/p/chromium/issues/detail?id=820929) > I've tested Chrome and Firefox, and both don't do any system font fallback when the given font contains a glyph for the b but don't for b + c1. > > I tested with 齋󠄁齋 (the first has a variation selector U+E0101 appended after it), and with a CSS declaration of `font-family: SimSun, HanaMinA;`, of which `SimSun` does not contain a glyph for the variation selector, but `HanaMinA` does: Can you clarify whether you were intending to test system fallback or fallback within the font-stack? If `HanaMinA` has coverage, no system fallback is needed, but browser should fall back from `SimSun` to `HanaMinA`. -- GitHub Notification of comment by drott Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/1710#issuecomment-372254103 using your GitHub account
Received on Monday, 12 March 2018 10:01:05 UTC