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 13:21:33 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-906408839-1629984092-sysbot+gh@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

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