[css-fonts-4][css-nesting] Nesting of @supports inside @font-face and font technology feature queries

[LeaVerou]

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);
	}
}

oder

@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 src 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.
• 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?

[svgeesus]

This seems obvious but checking just in case: your proposal @LeaVerou is to allow @supports inside any at-rule that has descriptors (so, not @charset for example), not solely on @font-face, right?

[LeaVerou]

Currently it is for @font-face. Obviously, it would be better to allow it in every at-rule, but I didn't want some unlikely combination of at-rule and @supports to hold up this proposal, so I figured we could start small and expand as use cases arise.

[drott]

CC @jfkthame

I'll investigate what that would entail from an implementation point of view (complexity, overhead) and comment once I have some findings.

One consideration from a readability point of view: If we introduce such a @supports rule, we will have both mechanisms: a list of entries in the src: descriptor (for example multiple url() entries potentially then "legacy" format("...") specifiers (with its own semantics of choosing the first compatible one from this list) and potentially multiple src: descriptors conditional on @supports blocks in the same @font-face rule, which I personally do not find great for consistency or readability. In other words, we would change the primary paradigm for src: selection to the @supports syntax but would still need to keep compatibility with the current approach of traversing a list of entries.

• It skips the parsing weirdness for src that this microsyntax has introduced

FWIW, the "parsing weirdness" may be considered addressed or improved with the most recent change which references the CSS syntax spec for parsing a comma separated list of components.

[emilio]

How is the supports rule represented in the OM? Implementation-wise I think it'd be easier for us if it just disappeared, but...

[LeaVerou]

Hi @drott!

One consideration from a readability point of view: If we introduce such a @supports rule, we will have both mechanisms: a list of entries in the src: descriptor (for example multiple url() entries potentially then "legacy" format("...") specifiers (with its own semantics of choosing the first compatible one from this list) and potentially multiple src: descriptors conditional on @supports blocks in the same @font-face rule, which I personally do not find great for consistency or readability. In other words, we would change the primary paradigm for src: selection to the @supports syntax but would still need to keep compatibility with the current approach of traversing a list of entries.

Yeah, this was raised by @plinss as well. The counter-argument he agreed to was that @supports came after format(), so while we're stuck with format() for legacy format selection, we shouldn't be actively developing two different feature detection mechanisms, one of which is entirely ad hoc and severely more limited.

FWIW, the "parsing weirdness" may be considered addressed or improved with the most recent change which references the CSS syntax spec for parsing a comma separated list of components.

I was referring to the fact that this descriptor's syntax needs prose and cannot be fully described by a grammar. I wasn't even aware that it used to be even weirder, whoa!

@emilio

How is the supports rule represented in the OM? Implementation-wise I think it'd be easier for us if it just disappeared, but...

I've wondered about this too, but I'm afraid making it disappear would be fairly inconsistent with every other @-rule, which would be even more confusing once Nesting is implemented.

[tabatkins]

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?

The big argument against is if we think multiple independent queries affecting different bits would be common; you'd have a combinatorial explosion to achieve equivalent results.

[tabatkins]

Looking at the proposal itself - it feels slightly weird to have context-specific @supports (I presume this wouldn't allow arbitrary property-support queries, but only font-based ones?). If I'm wrong about that and this would just be an ordinary @supports, with a supporting proposal to add the font-feature queries, then this is less weird. (If I'm right, naming it @font-supports or something would defuse my objection.)

I don't have a strong opinion on whether this should be treated as a parse-time syntax, disappearing from the tree in the OM, or kept around like normal @supports is. Parse-time is definitely simpler overall, but I understand how it feels new and odd.

Overall tho, I definitely support something like this over the growing weird microsyntax. The microsyntax was reasonable when it was just one thing, but it's getting out of hand.

[LeaVerou]

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?

The big argument against is if we think multiple independent queries affecting different bits would be common; you'd have a combinatorial explosion to achieve equivalent results.

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.

Looking at the proposal itself - it feels slightly weird to have context-specific @supports (I presume this wouldn't allow arbitrary property-support queries, but only font-based ones?). If I'm wrong about that and this would just be an ordinary @supports, with a supporting proposal to add the font-feature queries, then this is less weird. (If I'm right, naming it @font-supports or something would defuse my objection.)

It is not context-specific. The whole idea is that this way authors can use it to feature detect in any context that suits them, not just to differentiate the src, but possibly other aspects of their style.

[drott]

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

[LeaVerou]

I think adding the @supports criteria first, and implementing the nesting step later is a good path forwards.

Adding this to the agenda so we can resolve that these changes have CSS WG consensus.

[drott]

In this branch I drafted an edit to css-conditional-4, carrying over the syntax from fonts-4's - Parsing the source descriptor, an excerpt from that draft (feel free to comment on the commit directly as well):

<supports-feature> = <supports-selector-fn> | <supports-font-technology-fn> | <supports-decl>
<supports-selector-fn> = selector( <complex-selector> )
<supports-font-technology-fn> = font-technology ( <font-technology> )
<font-technology> = [ features( <font-feature-technology> ) | variations
                    | color( <color-font-technology> ) | palettes | incremental ]
<font-feature-technology> = [ opentype | aat | graphite]
<color-font-technology> = [ COLRv0 | COLRv1 | SVG | sbix | CBDT ]

Considerations:

• I did not add a repetition operator # after <font-technology> in the <supports-font-technology-fn> rule as required combinations of technologies can be expressed through and and oder of the @supports syntax, which I consider an improvement over the syntax in the fonts spec.

I'd be very happy if in tomorrow's meeting we could attempt to resolve towards a direction of the syntax along those lines (feedback very welcome), in addition to the general aim to resolve adding the criteria to the @supports rule.

[svgeesus]

I did not add a repetition operator # after in the rule as required combinations of technologies can be expressed through and and or of the @supports syntax, which I consider an improvement over the syntax in the fonts spec.

I agree, more readable that way.

[svgeesus]

Just to be sure I understand, the first example in the@font-face src explainer would become (repetitive, but readable; most desirable option is last):

/* 1. prefer COLRv1, then SVG-in-OpenType, then COLRv0 */
@font-face {
  font-family: jewel;
  src: url(boring.ttf) format("woff2");
}
@supports  font-technology(color(COLRv0)) {
    @font-face {
        font-family: jewel;
        src: url(jewel-v0.woff2) format("woff2");
    }
}
@supports  font-technology(color(SVG)) {
    @font-face {
        font-family: jewel;
        src: url(jewel-svg.woff2) format("woff2");
    }
}
@supports  font-technology(color(COLRv1)) {
    @font-face {
        font-family: jewel;
        src: url(jewel-v1.woff2) format("woff2"),;
    }
}

[drott]

Yes, that's how I would express it as well. That is: for now, without nested @supports.

[svgeesus]

@dbaron @fantasai thoughts? Since we are all editors of Conditional 3 I assume we are of Conditional 4 too, right?
@astearns @atanassov or would that need a separate resolution?

[svgeesus]

Oh wait

The declaration being tested must always occur within parentheses, when it is the only thing in the expression. source

So that is like

@supports  (font-technology(color(COLRv0))) {
   and so on

[LeaVerou]

Oh wait

The declaration being tested must always occur within parentheses, when it is the only thing in the expression. source

So that is like

@supports  (font-technology(color(COLRv0))) {
   and so on

This applies to declaration tests, not selector() oder font-technology() queries.

Nitpick, I don’t think we need nested function calls, not to mention color() might look confusing because of the other color() function. We could just prefix keywords with color- and feature-, which avoids the multiple nested parens.

[drott]

We could just prefix keywords with color- and feature-, which avoids the multiple nested parens.

Updated the proposed change with that suggestion, thanks.

[LeaVerou]

@svgeesus asked yesterday if we could use colons (font-technology(color: COLRv0)). I think that's not idiomatic to CSS and it's weird to have key-value pairs for some things and not others, but I'd defer to @tabatkins on that one. If he's ok with colons, I’m ok with colons.

[svgeesus]

So, that would be

/* 1. prefer COLRv1, then SVG-in-OpenType, then COLRv0 */
@font-face {
  font-family: jewel;
  src: url(boring.ttf) format("woff2");
}
@supports  font-technology(color-COLRv0) {
    @font-face {
        font-family: jewel;
        src: url(jewel-v0.woff2) format("woff2");
    }
}
@supports  font-technology(color-SVG) {
    @font-face {
        font-family: jewel;
        src: url(jewel-svg.woff2) format("woff2");
    }
}
@supports  font-technology(color-COLRv1) {
    @font-face {
        font-family: jewel;
        src: url(jewel-v1.woff2) format("woff2"),;
    }
}

[svgeesus]

it's weird to have key-value pairs for some things and not others

Its also weird to have key-value pairs multiple times for the same key

@supports font-technology(color: COLRv0) AND font-technology(color: COLRv1)

so on balance I prefer the hyphenated form proposed earlier.

[LeaVerou]

Resolved in today's meeting to discuss in breakout right before the regular meeting time next week. @drott could you please coordinate the logistics of said breakout?

[drott]

Yes, I'll send details and and invite to a Meet call to the private mailing list.

[fantasai]

@svgeesus From your example, format("color-COLRv1") and format("woff color-COLRv1") would both fail to load because neither string is a recognized font format.

[svgeesus]

Within the comma separated list, things are supposed to be space separated. Which is why

format(opentype supports incremental)

works in a backward compat way. As you say, older browsers treat the whole thing as one unknown format that happens to contain spaces.

[litherum]

@fantasai's proposal in #6520 (comment) makes sense to me.

Regarding the question of whether or not we can avoid changing the src descriptor, I think it comes down to how authors would implement fallback with @supports instead. Ideally, the same fallback code should be applied in both situations: 1) you're on an old browser that doesn't understand the new @supports syntax, and 2) You're on a new browser, but the browser doesn't actually support the font technology you're requesting. I think handling fallback for both these situations using the same code should be considered a requirement (otherwise it's too hard and authors will get it wrong).

A quick check shows that, in today's browsers (which are the first situation above),

@supports not font-format(truetype variations) {
    div {
        background: blue;
    }
}

does not cause <div>s to get blue backgrounds.

On the other hand,

@supports not ( font-format(truetype variations) ) {
    div {
        background: blue;
    }
}

does cause <div>s to get blue backgrounds. Maybe the solution is to change <supports-decl>'s definition from ( <declaration> ) to ( <declaration> | font-format(<font-format>) )? I'm not sure we can actually use this, though, because I think it was an intentional choice to make the thing between the parentheses a <declaration>.

If we can come up with a solution that satisfies these constraints, we can leave the src descriptor alone. However, if we can't, then I think we need to add expressiveness to the src descriptor because that's how authors would achieve correct fallback behavior.

---

Of course, another way to solve this problem is to wait to implement (but not necessarily spec) this fancy new @supports nesting stuff until after @else is implemented. That way, we would encourage authors to write code like

@supports font-format(truetype variations) {
    @font-face {
        /* variation font stuff */
    }
} @else {
    @font-face {
        /* fallback stuff */
    }
}

If these two features (@else, then @font-face nesting) were implemented in-order, we wouldn't need to modify the src descriptor. But, if they were implemented in reverse order, that would be bad unless we come up with some way of solving the problem described above (above the -----------).

[LeaVerou]

@litherum My understanding of the @supports grammar is that any negated condition needs to be in parens. If that's correct, that would explain why your first rule didn't work: because it's invalid syntax. Perhaps @tabatkins could confirm.

[drott]

I tend to agree with @LeaVerou here, with

<supports-condition> = not <supports-in-parens>
<supports-in-parens> = ( <supports-condition> ) …

(https://drafts.csswg.org/css-conditional-3/#at-supports)

only the second part of your example is valid syntax.

@supports not ( font-format(truetype variations) ) {
    div {
        background: blue;
    }
}

I am assuming the intent in your examples is to get blue background, or in other words: "use this block for fallback" is the intention.

It seems to me we we can conclude this syntax (with condition in parentheses) would fulfil your expectation of code a) working in old browsers without font-technology/font-format support, as well as b) in browsers that do understand the condition function.

[css-meeting-bot]

The CSS Working Group just discussed fonts, continued (beginning of log missing), and agreed to the following:

• RESOLVED: Modify src to allow for font-tech detection per URL
• RESOLVED: Same syntax available in src, will be available also in @supports, possibly with a font- prefix
• RESOLVED: remove "supports <font-technology>#"
• RESOLVED: add technology() and open bikeshedding issue
• RESOLVED: Add font-technology() and font-format() to @supports

The full IRC log of that discussion

<dbaron> topic: fonts, continued (beginning of log missing)
<dbaron> github: https://github.com//issues/6520
<lea> q?
<fantasai> astearns: jfkthame is suggesting to re-use format() not add new function
<fantasai> jfkthame: ...
<fantasai> chris: Because existing format function requires a font format
<fantasai> jfkthame: I don't see why not
<fantasai> jfkthame: would work just the same as not specifying format function at all
<fantasai> jfkthame: except now filtered by the tech keywords you just expressed
<lea> q+
<fantasai> drott: Currently state of format() is quite messy and not quite inteorp
<florian> q- later
<fantasai> drott: Some accept strings, some keywords, some both
<fantasai> drott: New function we have the potential of cleaning that up a bit
<drott> q-
<astearns> ack fantasai
<Zakim> fantasai, you wanted to ask about fallback in legacy browsers and to
<drott> q+
<fantasai> fantasai: One point about format() is it wouldn't invalidate src declaration in older browsers
<fantasai> fantasai: whereas a new function would
<fantasai> fantasai: As for jfkthame's proposal, I think it would work
<fantasai> fantasai: it would mean that the font-tech keywords would be in the same namespace as any format keywords, so you'd have to be careful to avoid name clashes
<fantasai> fantasai: but otherwise seems easily parsable
<drott> q-
<fantasai> astearns: One argument against format() is that then we can't use the same syntax in @supports, as context is lost has to be font-format()
<astearns> ack PeterCon
<fantasai> PeterCon: Might be edge case, but different tech ...
<fantasai> PeterCon: Variations technology is binary, font is either variable or not
<fantasai> PeterCon: feature capabilities are mutually exclusive
<TabAtkins> I think `@supports font-format()` works fine - the connection to @font-face's format() seems clear that you're qualifying it now that it's in a more generic context.
<fantasai> PeterCon: Font could have either AAT or Graphite, but impl only wants to use one or the other
<fantasai> PeterCon: If the font has both, perhaps author prefers one or other
<fantasai> PeterCon: So may want to specify which
<fantasai> PeterCon: In a fallback case, they might tolerate the second choice and not the first
<fantasai> PeterCon: Color tech is potentially complementary
<fantasai> PeterCon: Font might have both and use it for different glyphs
<fantasai> PeterCon: iN that case, might be happy to have both
<fantasai> PeterCon: An author potentially might say, I want to use this font but only use the ?? color list, not any of color-v0
<myles> q+
<fantasai> PeterCon: Idk if these are too edge case to worry about
<fantasai> drott: I don't think necessarily that we want to describe which part of font to use
<fantasai> drott: this is just syntax for ???
<fantasai> drott: I don't think we have tools for choosing the tech, that would be a separate thing
<fantasai> myles: ...
<drott> s/ ???/selection \/ download choice/
<fantasai> myles: It's not a subsetting feature
<chris> s/?? color/sbix color/
<astearns> ack lea
<fantasai> lea: It occurred to me that format wasn't originally for feature description, but to meta describe the URL
<fantasai> lea: This is a woff font, this is opentype
<fantasai> lea: [something about calling something woff but getting an opentype and whether it opens it or rejects]
<fantasai> myles: I think it's specced
<chris> format was added because we did not (at the time) have font MIME types
<fantasai> myles: If browser has already downloaded font, why should not use it?
<fantasai> lea: I thought it was defined to describe the resource
<chris> q?
<astearns> ack florian
<fantasai> lea: but maybe it was defined as feature detection?
<fantasai> fantasai: kinda was
<fantasai> florian: fantasai noted that putting both tech keyword would share namespace
<fantasai> florian: could have some syntax to divide, e.g. "with color-v1"
<fantasai> florian: Issue
<fantasai> florian: We say space-separated list is "and" not "or"
<fantasai> florian: fine, but might be two different meanings for "and"
<myles> [ ( woff | opentype | svg)? WITH [variations, color-sbix, opentype-features]# ]
<fantasai> florian: Do you support this and that?
<fantasai> florian: do you support both in the same file?
<fantasai> florian: slightly different question
<fantasai> florian: just to make sure this is forward proof might need to think about it
<astearns> q?
<astearns> ack myles
<fantasai> myles: Right now there's nothing in CSS that lets you say "use this part of the font, but not the other"
<fantasai> myles: I think that's good, because I don't think it's implementable
<fantasai> myles: I don't think we should add a feature that let's you ignore certain tables
<fantasai> fantasai: If we were to do so, I think it wouldn't be in src, should be its own descriptor
<drott> fantasai: if we would do that, it should be outside src descriptor
<fantasai> astearns: It sounds to me that we do have consensus to modify src descriptor to add font-tech detection somehow
<florian> Myles' sample syntax higher up is what I mean, except for the comas (and with an allowance for bikesheding the keyword WITH)
<fantasai> myles: Tab said something in IRC that made a lot of sense
<fantasai> myles: Could do jfkthame's idea for extending format()
<fantasai> myles: and have the same value syntax but different function name in @supports
<fantasai> fantasai: Yes, that was my proposal in the issue (using format() and font-format())
<florian> q?
<florian> q+
<fantasai> chris: Or we could use font-technology(), I'd prefer that
<fantasai> chris: but won't stand in the way
<lea> +1 to chris's point
<fantasai> chris: I think it's poor design to ???
<drott> s/???/throw it all in the format descriptor/
<fantasai> myles: I think if we're adding tech queries to @supports, should also allow format queries. So if we want distinct functions, then should have both in @supports
<drott> s/descriptor/function/
<fantasai> florian: Did anyone address fantasai's point about dropping the src descriptor if adding new function
<fantasai> florian: My understanding is if we extend format() will be OK, if add new function will throw out entire src declaration
<fantasai> myles: I'm not sure that distinction is true, thinking to how we parse src ...
<fantasai> myles: if you put format(keyword keyword) maybe it gets dropped entirely
<fantasai> florian: could put it all inside one string?
<fantasai> [no that's terrible]
<fantasai> myles: You do that by having two declarations
<fantasai> chris: Dropping one item in list is OK, dropping entire declaration is a bit of a problem
<fantasai> florian: If space-separated keywords in format(), do we drop the entire declaration or treat as unknown format?
<astearns> ack florian
<fantasai> chris: Unknown format
<fantasai> florian: probably should check implementations
<fantasai> lea: In my test seems like entire descriptor is dropped
<fantasai> florian: that's sad
<fantasai> lea: So I think we should use a new function
<fantasai> astearns: I think we can resolve that we add font-tech detection to src descriptor
<fantasai> astearns: is that the case? anyone arguing against and only wants @supports?
<lea> FYI to test I was using this: https://codepen.io/leaverou/pen/c02cfbe57388cca2399ee427c58e9f19 and checking what requests are sent to my localhost
<fantasai> RESOLVED: Modify src to allow for font-tech detection per URL
<fantasai> astearns: Next, can we decide on whether we're extending format() or adding new function?
<fantasai> lea: I just tested chrome
<fantasai> [fussing with the test]
<fantasai> florian: Another thing we can resolved, whichever form we add to add to src descriptor, we will expose that to @supports, possibly with font- prefix
<lea> Just tested Firefox, same
<fantasai> astearns: objections to that?
<fantasai> RESOLVED: Same syntax available in src, will be available also in @supports, possibly with a font- prefix
<drott> slight preference for font-technology
<fantasai> florian: ...
<lea> slight preference for font-tech as well
<fantasai> chris: Spec doesn't say, but fine to add that
<fantasai> astearns: I have a slight preference for a separate function, mainly because it makes the microsyntax we're adding slightly more clear
<fantasai> astearns: font-tech is not a format, and having two separate names for what you're specifying is very slightly better
<fantasai> myles: I'd like to hear from jfkthame
<florian> s/.../if we were to go for two functions, would both format and the new function be allowed in @support/
<drott> also solves migrating away from messy state of what format() is
<fantasai> jfkthame: I don't have a strong view one way or other, particularly if we don't get a forward-compat benefit from using format()
<drott> q+
<fantasai> jfkthame: To my mind these are very similar feature support queries, whether feature of a particular format or feature of a particular technology with the font
<astearns> ack drott
<fantasai> jfkthame: if people wnat to separate them, it's OK with me
<fantasai> drott: Do we remove the current ???
<fantasai> lea: yes
<fantasai> chris: Yes, that should all go
<fantasai> astearns: So we will add a font-technology() function with some amount of the keywords we've discussed
<fantasai> RESOLVED: remove "supports <font-technology>#"
<fantasai> florian: if we add format() to @supports, we have to add a font- prefix
<fantasai> florian: so shouldn't it be removed from font-technology() within src?
<fantasai> chris: Yes, let's be consistent
<fantasai> +1
<jfkthame> +1
<fantasai> lea: I thought one of the benefits was to be the same
<fantasai> astearns: but consistency is probably preferale
<fantasai> astearns: Any objections to technology()?
<florian> tech? capability?
<fantasai> fantasai: No, but I would prefer a shorter name if we can find one
<fantasai> lea: yes, please
<fantasai> RESOLVED: add technology() and open bikeshedding issue
<lea> given that Chrome needs to ship this soon, if we don't bikeshed soon, it's just de facto font-technology
<fantasai> RESOLVED: Add font-technology() and font-format() to @supports
<fantasai> with same syntax within the parentheses
<fantasai> drott: do we need both?
<florian> q+
<fantasai> astearns: prefer to add now, if ppl have objections can remove in the future, but seemed there were some use cases
<fantasai> florian: Point about "and" having two meanings, is it a concern?
<astearns> ack florian
<lea> what if we just add format-* keywords to font-technology()?
<fantasai> fantasai: You're "and"-ing over a single font file...
<fantasai> myles: The question is what if browser supports two different technologies, but not in the same font
<fantasai> florian: I guess you just choke on trying the use the download, which is wasteful but maybe not an issue
<fantasai> PeterCon: The example you gave was variable font with SVG table
<fantasai> PeterCon: likelihood of creating such a font is not great
<fantasai> myles: there's no way to describe variableness in SVG
<fantasai> Meeting closed.

[astearns]

Full minutes posted here: https://www.w3.org/2021/10/20-css-minutes.html

[astearns]

Since this issue thread is really long and pulls in a lot of related topics, please consider opening new focused issues based on the resolutions above and/or the spec edits that will be made soon. For instance, if we need to bikeshed the technology() term it would be better to have a new issue just for that. Or if the keywords edited in for the new function need changes, that would be excellent as a separate issue.

[svgeesus]

Edits made to CSS Conditional 4, CSS Fonts 4, and CSS Fonts 5.

[svgeesus]

Extensions to the @supports rule
Parsing the src descriptor (4)
and
Parsing the src descriptor (5)
Font formats
Font technologies

[LeaVerou]

Extensions to the @supports rule Parsing the src descriptor (4) and Parsing the src descriptor (5) Font formats Font technologies

I thought we could get rid of the parsing weirdness around src now?

[svgeesus]

I thought we could get rid of the parsing weirdness around src now?

We got rid of the weirdness around format supports whatever. We still have a descriptor wchich is a comma-separated list of items, where each item is a url() followed by an optional format() and an optional technology() so we still need to describe how to work out the winning item.