[css-fonts-4][css-nesting] Nesting of @supports inside @font-face and font technology feature queries #6520
Description
This is related to #633 and this part of css-fonts-4: https://drafts.csswg.org/css-fonts-4/#font-face-src-parsing
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 to allow nesting of conditional rules inside regular rules, so that authors can do things like:
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:
@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
@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:
@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
srcthat 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.
- It can be used in JS as well, through the existing
CSS.supports()API (current syntax also allows programmatic detectability but in a much clunkier way - 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
There are no implementations of the current syntax, so it may not be too late for the change.
Thoughts, @svgeesus @litherum @fantasai @tabatkins?