- From: Dominik Röttsches via GitHub <sysbot+gh@w3.org>
- Date: Tue, 23 Aug 2022 13:51:44 +0000
- To: public-css-archive@w3.org
> (1) The [syntax for font-format()](https://drafts.csswg.org/css-conditional-5/#typedef-supports-font-format-fn) appears to accept only keywords, whereas the format() function in the CSS Fonts [@font-face src descriptor](https://drafts.csswg.org/css-fonts-4/#font-format-values) 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()](https://drafts.csswg.org/css-conditional-5/#typedef-supports-font-tech-fn) accepts a single keyword identifying a font technology. In contrast, the [tech() function in CSS Fonts](https://drafts.csswg.org/css-fonts-4/#font-face-src-parsing) 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 `AND`ed 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. -- GitHub Notification of comment by drott Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7633#issuecomment-1224107895 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 23 August 2022 13:51:46 UTC