- From: jfkthame via GitHub <sysbot+gh@w3.org>
- Date: Thu, 26 Aug 2021 13:51:47 +0000
- To: public-css-archive@w3.org
> As you noted, using `unicode-range:` for declaring the supported range does make this problem disappear altogether. In my opinion, high performance font loading strategies should and do already declare unicode-range, tools like [Wakamai Fondue's beta version](https://wakamaifondue.com/beta/) help in declaring it, Google Fonts does it for subsetting into script ranges. I find that an acceptable tool and established strategy for authors who care about font performance. Yes, I'm aware of how Google Fonts (for example) uses `unicode-range` to split fonts into script ranges. For a major service that can invest in tooling and expertise to do this, that's clearly beneficial for performance. I'm still a bit concerned, though, about the case of an author who is, for example, just adding a custom icon, logo or in-house decorative/branding font to a site, and hand-writing the CSS to support it; this is the kind of scenario where it's easy to imagine authors writing code along the lines of [the example above](https://github.com/w3c/csswg-drafts/issues/6520#issuecomment-906384393), without realizing that they're causing redundant resource loads. The CSS spec even [suggests](https://drafts.csswg.org/css-fonts-4/#unicode-range-desc) that it's reasonable to use broad-range `unicode-range` descriptors rather than enumerating the precise coverage of the font: > When the font is used, the **effective character map** is the intersection of the codepoints defined by 'unicode-range' with the font’s character map. This allows authors to define supported ranges in terms of broad ranges without worrying about the precise codepoint ranges supported by the underlying font. So an author might quite reasonably write `unicode-range: U+1f6??` for an icon font that includes a sparse subset of the entire 1F6xx block; but then if a symbol from that block *not* covered by the webfont is encountered, *all* the fallback versions will be fetched before finally resorting to the system's standard emoji font. I think we should try to design the solution here such that authors who write their font-enrichment CSS in the "natural" way do not thereby create a hidden performance drag. Quite how best to do that isn't yet clear to me. -- GitHub Notification of comment by jfkthame Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6520#issuecomment-906433337 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 26 August 2021 13:51:49 UTC