W3C home > Mailing lists > Public > public-css-archive@w3.org > August 2021

Re: [csswg-drafts] [css-fonts-4][css-nesting] Nesting of @supports inside @font-face and font technology feature queries (#6520)

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
Message-ID: <issue_comment.created-906368938-1629981321-sysbot+gh@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

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 06:42:42 UTC