- From: jfkthame via GitHub <sysbot+gh@w3.org>
- Date: Thu, 26 Aug 2021 09:16:20 +0000
- To: public-css-archive@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