[css-conditional-4] Extend supports feature to express font capabilities

[drott]

Define criteria for enabling @supports to distinguish support for
a set of font technologies defined in the grammar.

Addresses resolution in #6520 to add criteria for font technologies as a
first step.

Incorporates @LeaVerou 's feedback from [1]

[1] #6520 (comment)

[drott]

@litherum wrote:

Please add a note saying this is not ready for implementation yet (though similar/identical grammar is ready for implementation inside the src: descriptor). It also might be worth saying that implementing this depends on implementing @else.

[drott]

From the minutes:

#6520 (comment)

<fantasai> RESOLVED: Accept the PR
<chris> :)
<fantasai> myles: Can we add a note to the PR to say "don't implement this yet, implement this other thing first"
<fantasai> astearns: open an issue

[drott]

I suggest we merge this, as was discussed, and decide on the form of the note in a separate issue / PR.

From my point of view, no objections to a note saying, for example: "Implementers should consider shipping this in combination with an @else addition to @supports . Changes to details of the grammar are still expected."

It also might be worth saying that implementing this depends on implementing @else.

I don't think this matches what was resolved.

CC @fantasai

[litherum]

Implementations should not ship the @supports feature without @else, because if you only give authors the wrong way to do something, they're going to do it wrong.

Implementations may ship the src: feature without @else.

The syntaxes for @supports and src: can be unified, too (as @fantasai requested during today's call).

This gives Chrome a natural path to shipping - first, the WG can unify the syntaxes for @supports and src:, and then Chrome can ship the new and improved src: syntax while the WG works on @else. Then, when @else is ready, that can ship alongside the new and improved syntax in @supports. I believe this makes everyone happy.

[litherum]

@jfkthame

[LeaVerou]

@litherum as discussed in the call, please open a new issue about this. We have a resolution to merge this PR, and it is not appropriate to be making substantive changes to a PR we have already resolved to merge.