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

> 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 using your GitHub account

Sent via github-notify-ml as configured in

Received on Thursday, 26 August 2021 12:35:24 UTC