- From: Lea Verou via GitHub <sysbot+gh@w3.org>
- Date: Sat, 21 Aug 2021 00:23:06 +0000
- To: public-css-archive@w3.org
> While it would involve more duplication, would it be okay to just leverage @supports normally, with some new queries to ask about various font-feature support, and then just have @font-face as a child of the rule like normal? > > The big argument against is if we think multiple independent queries affecting different bits would be common; you'd have a combinatorial explosion to achieve equivalent results. I think that could be a good first step, and would enable authors to do what they want with some duplication. However, we do eventually want to avoid the duplication, even if multiple independent queries aren't common. > Looking at the proposal itself - it feels _slightly_ weird to have context-specific @supports (I presume this _wouldn't_ allow arbitrary property-support queries, but only font-based ones?). If I'm wrong about that and this would just be an ordinary @supports, with a supporting proposal to add the font-feature queries, then this is less weird. (If I'm right, naming it `@font-supports` or something would defuse my objection.) It is not context-specific. The whole idea is that this way authors can use it to feature detect in any context that suits them, not just to differentiate the `src`, but possibly other aspects of their style. -- GitHub Notification of comment by LeaVerou Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6520#issuecomment-903018854 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Saturday, 21 August 2021 00:23:08 UTC