[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:

• [css-fonts] @font-face src: url() format() keywords vs. strings ambiguous in spec #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 548dab8 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

• Pluralize feature-* to features-*? #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"