- From: jfkthame via GitHub <sysbot+gh@w3.org>
- Date: Sun, 24 Mar 2024 14:56:55 +0000
- To: public-css-archive@w3.org
jfkthame has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-fonts] @font-face source: reference to OpenType Collection without a fragment identifier == It's unclear to me from the current text at https://www.w3.org/TR/css-fonts-4/#font-face-src-loading exactly what a UA should do if the source referenced by a `@font-face` rule is a collection, but no fragment identifier is provided to specify which face from the resource is to be used. We're told: > [F]ont container formats that can contain more than one font must load one and only one of the fonts for a given `@font-face` rule. Fragment identifiers are used to indicate which font to load; these use the PostScript name of the font as defined in [[RFC8081]](https://www.w3.org/TR/css-fonts-4/#biblio-rfc8081). We're also told: > Conformant user agents must skip downloading a font resource if the fragment identifier is unknown or unsupported. I think it would be reasonable for this also to apply to the case of a missing fragment identifier, but I don't think the spec makes this clear. Perhaps this sentence should be expanded to say "...if the fragment identifier is absent, unknown, or unsupported"? An alternative might be to say that in the absence of a fragment identifier, the UA loads the first defined font in the collection. This would be similar to the behavior for SVG fonts, mentioned just above: > If the element reference is omitted, a reference to the first defined font is implied. but on the other hand, the WG has in the past specifically opposed selecting fonts by their index in OpenType collections, insisting that names must be used. So it seems hard to justify making an exception whereby a missing fragment identifier equates to selecting the face at index zero. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10127 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Sunday, 24 March 2024 14:56:56 UTC