w3c
[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-facerule. Fragment identifiers are used to indicate which font to load; these use the PostScript name of the font as defined in [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.
An alternative might be to say that in the absence of a fragment identifier, the UA loads the first defined font in the collection.
That seems the simplest and easiest option. But the spec should not that this is fragile: the font might get updates such that the "first" font changes.
the WG has in the past specifically opposed selecting fonts by their index in OpenType collections,
IIRC that was feedback (when RFC8081was being developed) from font vendors, in particular Adobe, who gave examples of updates to in-the-wild collections which had changed the index numbers.
ISTM that explicitly saying a collection without a fragment ID (font name) is ignored as invalid would be just as straightforward, and more consistent with the general rejection of indexing into the collection.
I'd argue that if no fragment is provided in the src: url(...) descriptor, the URL's fragment is null (per https://url.spec.whatwg.org/#url-representation), and therefore a strict reading of the Fonts spec implies that we have to select a face from the collection whose PostScript name is null; any font with a non-null psname clearly does not satisfy this URL.
So on reflection, I think that's the most reasonable reading, and should be made explicit in the spec (rather than having a fragile index-based default).
While we're here, I'd also like to take issue with the wording of
Conformant user agents must skip downloading a font resource if the fragment identifier is unknown or unsupported.
because AFAICT the user agent cannot know whether the fragment identifier is known or not (as the postscript name of a face in the collection) until it has downloaded the resource. So it's too late to "skip downloading", unless the UA can determine that the fragment identifier cannot be a valid postscript name (e.g. because it contains characters that would be illegal).
So maybe something more like
Conformant user agents must not use a face from the resource unless its PostScript name exactly matches the fragment identifier, and should skip downloading the resource if the given fragment identifier cannot be a valid PostScript name.
Adopted suggested wording, but retained must skip from the existing wording, rather then suggested should skip