- From: Dominik Röttsches via GitHub <sysbot+gh@w3.org>
- Date: Thu, 09 Sep 2021 15:49:18 +0000
- To: public-css-archive@w3.org
> The CSS spec even suggests that it's reasonable to use broad-range unicode-range descriptors rather than enumerating the precise coverage of the font: I'd be in favour of changing that recommendation. In the discussion so far, I see these constraints - am I missing something, or are there differing views? 1. Due to implementation complexity and CSSOM implications it's harder to put `@supports` inside `@font-face` so we seem to agree on a preference to have it at the top level. 2. If `@support` + a `font-technology()` function is placed at the top level, we may run into the cascading / accumulation issue (with varying opinions on how sever that issue is). 3. If we define a `font-technology()` supports function, nothing per-se stops it from being used at the top-level. Options we've been pondering in an internal discussion: - Add a new descriptor to `@font-face` remotely similar to a C++ `final` keyword - meaning that there shouldn't be further search for other segmented font faces in the same family. This would require people to use it, otherwise the same cascading problem remains. And due to the fact it needs to be actively used it becomes somewhat redundant with `unicode-range` which addresses the same issue. Alternatively, but probably too intrusive, have a new `@font-face-no-cascade` (name to be bikeshod) with a different matching algorithm / cascading behavior? - Would it be useful to define something like a `url()` alias blob object to point to a `url()` resource inside a top-level `@supports` - then use that alias/reference in a `src:` descriptor inside `@font-face`s? Are there precedents for something like that? - If we don't want `@supports` at the top level and despite the implementation hurdles opt for a nested approach, add prose to the new `font-technology()` function that it resolves to false when used outside the nested scope? -- GitHub Notification of comment by drott Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6520#issuecomment-916221329 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 9 September 2021 15:49:20 UTC