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: Dominik Röttsches via GitHub <sysbot+gh@w3.org>
Date: Thu, 26 Aug 2021 10:35:07 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-906288459-1629974106-sysbot+gh@w3.org>
> 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.

I don't completely disagree, but I don't think combinations of shaping engine choice and other capabilities are very likely when there are barely any aat and graphite web fonts used let alone color or variable versions of those. I consider the most likely scenarios are variations yes/no, and perhaps 1-3 color technologies as a fallback ladder.

> 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_.

This "performance gotcha" only arises when you really have different glyph sets and that is a surprise to you as the author or font provider who delivers that CSS and the fallback font would be loaded inadvertently to check for glyph coverage. 

For language/script subset fallback `unicode-range` is an established and widely used technique to control that. 

For color- or variations-enhanced upgrades of a monochrome static font the glyph sets are (as you mentioned yourself) likely identical. If not, `unicode-range` is used to guard control fall through. In most cases, CSS and fonts are delivered from the same provider who knows the fonts' coverage. For those reasons, overall, my impression is, an accidental fall-through performance gotcha does not seem a likely footgun. I would agree with @dbaron that this seems working as intended.

A solution that avoids this _accumulation_ issue is `@supports` inside `@font-face` which we can spec already by adding the css-conditionals-4 `font-technoloy()` function and allowing `@supports` nesting inside `@font-face`. Feasible for us from an implementation point of view short-term is `@font-face` inside `@supports`, nesting only later, but we are supportive of allowing and implementing that in general, it will just take more time. Would this perspective / progression be sufficient for addressing your concerns, @jfkthame ?

Another solution that avoids this _accumlation_ issue is for example to modify the font matching algorithm based on an additional technology descriptor, or going back to some kind of technology-tagging in the `src:` line. I think both those avenues would lead to micro-syntaxes external to `@supports`.

GitHub Notification of comment by drott
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6520#issuecomment-906288459 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 10:35:10 UTC

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