- From: Dominik Röttsches via GitHub <sysbot+gh@w3.org>
- Date: Mon, 23 Aug 2021 15:00:53 +0000
- To: public-css-archive@w3.org
Having looked at and discussed with my CSS colleagues, the implementation of `@supports` inside the `@font-face` at-rule, would be a larger effort, in particular if the `@supports` rules need to be represented in the CSSOM, which poses problems given the current internal representation. (In addition, we're blocked on some parser refactoring which would make this more difficult, but that's an internal issue). >> 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? > I think that could be a good first step, and would enable authors to do what they want with some duplication, and would likely (?) be relatively easy to implement. However, we do eventually want to avoid the duplication, even if multiple independent queries aren't common. Yes, I agree, adding something similar to a `<supports-font-technology-fn>` to **[2. Extensions to the @supports rule](https://www.w3.org/TR/css-conditional-4/#at-supports-ext)** with syntax similar to what is in the current font spec proposal is immediately useful for the desired feature detection through `CSS.supports()` JavaScript and would immediately work at the top level (not nested). This would give us a path that's relatively straight-forward to implement and not blocked on nesting `@supports` inside `@font-face`, while it would still allow for that kind of nesting later and migrating away from unnecessary `@font-face` repetition. -- GitHub Notification of comment by drott Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6520#issuecomment-903852298 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 23 August 2021 15:00:55 UTC