Chris Lilley
Chris Lilley
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
> Could you split out (3) into a separate issue - https://github.com/w3c/csswg-drafts/issues/7663
> 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...
> 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...
OK great, I will add that exact list to the spec, then.
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...
I notice we have this left-over section [format strings](https://drafts.csswg.org/css-fonts-4/Overview.html#font-format-definitions) which is originally from [CSS Fonts 3](https://drafts.csswg.org/css-fonts-3/Overview.html#src-desc). It is older, in that it describes the obsolete SVG font format and doesn't...
But regardess of naming yes, I think we should have such a getter
> In https://github.com/w3c/csswg-drafts/commit/d3db8697852a6ccc1c8dafcb4aff1f516198bb50, the `font-variant` descriptor of the `@font-face` rule was dropped, resolving https://github.com/w3c/csswg-drafts/issues/2531. Right. > However, the `FontFace` interface still has the `variant` attribute: https://www.w3.org/TR/css-font-loading-3/#fontface-interface I think that is...