[csswg-drafts] [css-fonts-4][css-nesting] Nesting of @supports inside @font-face (#6520)

LeaVerou has just created a new issue for https://github.com/w3c/csswg-drafts:

== [css-fonts-4][css-nesting] Nesting of @supports inside @font-face ==
This is related to #633 .

A bit late to the party, but I wondered: what if, instead of adding yet another microsyntax for feature detection, we use `@supports` with an appropriate `font-technology()` function (or whatever we want to name it)?

We [recently resolved](https://github.com/w3c/csswg-drafts/pull/6483) to allow nesting of conditional rules inside regular rules, so that authors can do things like:

```css
a {
 color: red;

 @supports (foo: bar) {
  color: green;
 }
}
```

What if this was allowed in `@font-face` as well? That way, authors could do something like:

```css
@font-face {                                                                                                                                     
 font-family: Foo;
 src: url("foo.woff2") format("woff2");
 
 @supports font-technology(variations) and font-technology(COLR) and font-technology(palettes) {                                                                                                                          
  src: url("foo.woff2") format(woff2);
 }
}
```

or 

```css
@font-face {                                                                                                                                     
 font-family: Foo;
 src: url("foo.woff2") format("woff2");
 
 @supports font-technology(variations COLR palettes) {                                                                                                                          
  src: url("foo.woff2") format(woff2);
 }
}
```

instead of:

```css
@font-face {                                                                                                                                     
 font-family: Foo;
 src: url("foo.woff2") format("woff2");                                                                                                                              
 src: url("foo.woff2") format(woff2 supports variations color(COLR) palettes);                                                               }
```

Benefits:
- It reuses existing syntax, and can be extended to other types of rules in the future, if needed
- It skips the [parsing weirdness for `src`](https://github.com/w3c/csswg-drafts/issues/2920) that this microsyntax has introduced
- It can be used elsewhere, to allow authors to branch their styling differently based on whether these capabilities are allowed. I'd imagine loading a monochrome font over a color font, or a non-variable font would require a fair bit of style differentiation beyond which font is being loaded.
- Authors can decide which descriptors to vary, e.g. they may wish to give the color/variable font a different name
- Arguably easier to read. I find the current proposal quite hard to read, as everything in `format()` is a list of keywords, with no hierarchy. Also, the syntax makes it unclear whether this is a feature query for the browser, or informing the browser what the font file supports.

Downsides:
- I'm hoping UAs can implement this as a one-off, without implementing CSS Nesting in its entirety. My understanding is the functionality is needed _yesterday_, so introducing a big blocker would not be desirable. Would appreciate thoughts from implementors here.
- More verbose

Unlike conditional rules in general, feature queries do not change during the lifetime of the page load, and thus this should not trigger re-interpretation of the `@font-face` rule or be more heavyweight in any other substantial way.

If such syntax is used with today's browsers, they drop the `@supports` rule but keep the `@font-face` rule, so it does appear forwards compatible. [testcase](https://codepen.io/leaverou/pen/eYWapoO)

There are no implementations of the current syntax, so it may not be too late for the change.

Thoughts, @svgeesus @litherum @fantasai @tabatkins?

Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6520 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Monday, 16 August 2021 16:02:44 UTC