- From: jfkthame via GitHub <sysbot+gh@w3.org>
- Date: Thu, 26 Aug 2021 11:18:35 +0000
- To: public-css-archive@w3.org
> This "performance gotcha" only arises when you really have different glyph sets No, my point is the performance issue arises when the preferred and fallback fonts have the *same* glyph set (and precisely-enumerated `unicode-range` descriptors have not been used). In this case, when a character isn't supported by the preferred font, the browser will have to load the fallback *as well* in order to check its glyph coverage, which will be purely wasted time and bandwidth. Nesting `@supports` inside `@font-face` would make it easier (as an author) to structure things efficiently, but I am not sure about the implementation complexity issues at this stage. We should also think about how adding nested-`@supports` at a later stage will work for authors who need to account for older UAs that don't support that. It'd be interesting to see an example of what the eventual CSS should look like for a page that wants to use nested `@supports` inside `@font-face` if available, falling back to `@font-face` inside `@supports` for earlier browsers. -- GitHub Notification of comment by jfkthame Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6520#issuecomment-906316112 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 11:18:36 UTC