[css-conditional-5] Queries re font-technology support queries

[jfkthame]

The Conditional Rules level 5 spec extends @supports with new font-tech() and font-format() functions. In looking to implement these, a few minor questions have come up that I'd like to clarify/confirm.

(1) The syntax for font-format() appears to accept only keywords, whereas the format() function in the CSS Fonts @font-face src descriptor accepts either a keyword or a string. While I think keywords are preferable here, I wonder whether we should also accept the string syntax in @supports font-format(...) for consistency with the @font-face descriptor?

(2) The syntax for font-tech() accepts a single keyword identifying a font technology. In contrast, the tech() function in CSS Fonts accepts a comma-separated list of font technology keywords. Should @supports font-tech(...) similarly accept a list?

(3) A really minor issue, but I have found myself repeatedly writing things like @supports font-tech(features-opentype), and not getting the expected result because the correct keyword is feature-opentype (singular). To my mind, the feature-* keywords would read more naturally in the plural form (similarly to font-tech(variations)). Should we change them to plural, here and in CSS Fonts, before this is widely implemented and webcompat becomes a constraint?

[jfkthame]

cc @drott

[svgeesus]

The syntax for font-format() appears to accept only keywords, whereas the format() function in the CSS Fonts @font-face src descriptor accepts either a keyword or a string.

I'm sure I remember this being discussed in an issue, and we decided to try for just keywords, but I looked and can't find it. Does this ring bells for anyone else?

[svgeesus]

The only related issue I can find seems to conclude we should accept both strings and keywords:

• https://github.com/w3c/csswg-drafts/issues/6328

[drott]

(1) The syntax for font-format() appears to accept only keywords, whereas the format() function in the CSS Fonts @font-face src descriptor accepts either a keyword or a string. While I think keywords are preferable here, I wonder whether we should also accept the string syntax in @supports font-format(...) for consistency with the @font-face descriptor?

I'd rather reduce the use of strings and agree with you that keywords are preferable here. The relevant issue that @svgeesus uncovered, #6328 has more of the discussion. IMO strings are accepted there for backwards compatibility and the only strings allowed in CSS @font-face src: lines in format() should be the ones that were at some point specified in the spec, meaning: "woff", "truetype", "opentype", "woff2", "embedded-opentype", "woff2-variations". So I'd be in favour of not relaxing the definition in the Conditionals spec to allow strings.

(2) The syntax for font-tech() accepts a single keyword identifying a font technology. In contrast, the tech() function in CSS Fonts accepts a comma-separated list of font technology keywords. Should @supports font-tech(...) similarly accept a list?

No strong opinion, but I think the idea for the @when rule is to group multiple @supports conditions/queries with boolean algebra. I don't think we need to repeat a definition that a comma separated list would mean the ANDed combination of such requested font technology keywords, as that can be expressed with @when (at least in the future).

(3) A really minor issue, but I have found myself repeatedly writing things like @supports font-tech(features-opentype), and not getting the expected result because the correct keyword is feature-opentype (singular). To my mind, the feature-* keywords would read more naturally in the plural form (similarly to font-tech(variations)). Should we change them to plural, here and in CSS Fonts, before this is widely implemented and webcompat becomes a constraint?

+1 to changing to the plural form. Looking at this edit 548dab8299f12048688043e2f1291d93c3d85eb2 when we moved from supports() to technology() it read as features(<tech>) before so I think it makes sense to have these read as plural forms.

[jfkthame]

Re (2), I agree that for @supports, it will be possible to use boolean algebra to specify an ANDed combination of technologies, so supporting multiple tech keywords within font-tech(...) isn't essential. But the draft does currently say that:

The allowed values for the 'font-tech()' function are the same as those for the 'tech()' function in the '@font-face/src' descriptor

which makes it sound as though whatever you can say in tech(...) within a @font-face rule should also be usable in font-tech(...) here. But then the syntax only allows for a single keyword.

I don't feel strongly one way or the other about this, but I guess I do lean towards consistency between the @font-face and @supports forms, as I think that'll be less confusing for authors.

[drott]

@jfkthame Could you split out (3) into a separate issue and perhaps we can resolve that quickly? That, I think, would enable shipping the feature while we continue discussing additional argument types (strings) or multiple arguments.

[svgeesus]

Could you split out (3) into a separate issue

• https://github.com/w3c/csswg-drafts/issues/7663

[svgeesus]

I don't feel strongly one way or the other about this, but I guess I do lean towards consistency between the @font-face and @supports forms, as I think that'll be less confusing for authors.

I think consistency here was the original design intent.

[svgeesus]

I wonder whether we should also accept the string syntax in https://github.com/supports font-format(...) for consistency with the https://github.com/font-face descriptor?

IMO strings are accepted there for backwards compatibility and the only strings allowed in CSS @font-face src: lines in format() should be the ones that were at some point specified in the spec, meaning: "woff", "truetype", "opentype", "woff2", "embedded-opentype", "woff2-variations". So I'd be in favour of not relaxing the definition in the Conditionals spec to allow strings.

If we do decide to retain keywords-only for Conditional, I suggest adding a note in Fonts like:

Note: for backwards compatibility, this descriptor also accepts a string, which must be one of the following: "woff", "truetype", "opentype", "woff2", "embedded-opentype", "woff2-variations". The CSS WG does not expect to increase the set of accepted strings.

[jfkthame]

That sounds good, with one adjustment: it wouldn't ever have made sense to recognize only "woff2-variations" but not "-variations" variants of the other formats, and indeed Firefox (at least) does also recognize "truetype-variations", "opentype-variations", and "woff-variations". The existing WPT test at css/css-fonts/format-specifiers-variations.html also expects these strings to be accepted.

[drott]

it wouldn't ever have made sense to recognize only ...

Agree, looking at the source I found that we accept: "woff", "truetype", "opentype", "woff2", "collection", "woff-variations", "truetype-variations", "opentype-variations", "woff2-variations"

[svgeesus]

OK great, I will add that exact list to the spec, then.

[svgeesus]

I'm writing:

While keywords are preferred to identify font formats, for reasons of backwards compatibility the following strings are also accepted, and have the same effect as if the equivalent modern syntax had been used.

and want to add

Any other strings are ... what?

Treated as if no format had been specified?

[drott]

Any other strings are ... what?

In my prototype implementation, I am rejecting those entries of the src: line and not adding them to the list of supported resources. Reasoning being: If it's a format that the UA hasn't heard of, there's not much point in trying this resource. And that behaviour is what I would suggest specifying. Curious to hear @jfkthame's point of view.

[svgeesus]

I notice we have this left-over section format strings which is originally from CSS Fonts 3.

It is older, in that it describes the obsolete SVG font format and doesn't have the short-lived foo-variations strings. On the other hand it does have nice links to the actual format definitions.

Looks like I should merge these two, moving the recently added table here, and then adding a column with the links to format specifications.