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: jfkthame via GitHub <sysbot+gh@w3.org>
Date: Thu, 26 Aug 2021 09:16:20 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-906237102-1629969378-sysbot+gh@w3.org>
> Do note that instead of `unicode-range` (which would be a pain, I agree), one could also use `not` in `@supports` instead of having a bare `@font-face` as the fallback.

Yes, using `@supports not ...` would avoid this. That gets a bit cumbersome in complex cases: e.g. if there are two or three color-font techologies being queried, as well as variations and a couple of shaping technologies, the `@supports` rule wrapping the fallback that doesn't support any of these could become pretty unwieldy.

It also feels like a footgun because it *differs* from how `@supports` normally interacts with graceful degradation. With typical CSS properties, the user can write the generic fallback first, then write the more-sophisticated version in an `@supports` rule, expecting it to *override* the fallback if it's supported. The performance "gotcha" here arises because `@font-face` rules do not *override* previously-defined ones for the same descriptors; instead, they *accumulate*.

GitHub Notification of comment by jfkthame
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6520#issuecomment-906237102 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 09:16:22 UTC

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