- From: Dominik Röttsches via GitHub <sysbot+gh@w3.org>
- Date: Thu, 26 Aug 2021 13:21:33 +0000
- To: public-css-archive@w3.org
After your explanations @jfkthame , I agree that the behaviour with `@supports` in that sense would be different from what was in the fonts spec, where only the first, highest-capability-tagged resource of listed supported resources in the `src:` line would be loaded for a glyph for which there is no coverage. 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. Also agree with @LeaVerou that catch-all aliases help with describing negative `@supports` rules to exclude fonts from the set. -- GitHub Notification of comment by drott Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6520#issuecomment-906408839 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:21:35 UTC