- From: Dominik Röttsches via GitHub <sysbot+gh@w3.org>
- Date: Thu, 26 Aug 2021 12:35:22 +0000
- To: public-css-archive@w3.org
> 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. I don't understand. If they have the same glyph set, and same CMAP coverage - why would a character then _not_ be supported by the preferred font? The load for the fallback only needs to be triggered if the primary font doesn't have coverage and such was determined during font analysis or shaping, but if coverage was already found, no load is needed. In the case of color and variations upgrades of a conventional font with same glyph set, when would such a situation really be the case? -- GitHub Notification of comment by drott Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6520#issuecomment-906368938 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 12:35:24 UTC