[css-fonts] Unknown fragment identifiers in @font-face src:

[litherum]

In the src: descriptor of @font-face, the author can include a fragment identifier to indicate a particular font of a collection should be used. As of d4e0597 it's unclear what to do if the fragment identifier doesn't identify any font in the file.

There are probably two possibilities:

• Use the first one in the file
• Classify this situation as an error, and mark the url as failed

[litherum]

@svgeesus

[litherum]

Option 2 is probably bad because that's not how fragment identifiers work in any other situation. For example, if you navigate to an html page with a bogus fragment identifier, the UA will scroll to the top of the new page. I think this is the equivalent of option 1.

[svgeesus]

Agreed, the first font found should be the behavior.

Edited to add: changed my mind, see below.

[tabatkins]

Option 2 is probably bad because that's not how fragment identifiers work in any other situation.

Note that it is how unknown fragments work in image(), so that authors can get similar backwards-compatible behavior to how property fallback works. For example, you can do image("foo.jpg#newFragType(bar)", "manuallyApplied.jpg"), falling back to the "manuallyApplied.jpg" image if the first either doesn't load or the UA doesn't understand the fragment type.

[litherum]

.jpg files don't accept any fragments, though. I'm confused.

[tabatkins]

1. Yes they do! image() support requires that implementations support the #xywh version of Media Fragments.

2. That's the point - they don't yet, and so any use of fragments (beyond MF, as mentioned previously) will result in the image being rejected and moving on to the next one. So there's precedent for this kind of behavior, rather than just ignoring the fragment and making assumptions about the file.

[svgeesus]

Hmm. I do find this use case compelling:

image("all-icons.png#xywh=256,160,32,32", "icon_8_5.png")

where all-icons has all the icons together in a grid and uses media queries to crop out a specific one; the fallback is to download the individual image icons.

Similarly, if browsers ever supported OpenType Collection fonts, one would not want the 'first available' font to be selected (and while they don't, you would want the fallback font to be used:

src: url(SomeFont.otc#CondensedUltaSomething, CondensedUltaSomething.otf)

So I'm persuaded by @tabatkins argument.

[upsuper]

src: url(SomeFont.otc#CondensedUltaSomething, CondensedUltaSomething.otf)

I don't think we want to use url function for this. It should either have a new function like image, or just rely on the fallback mechanism of src descriptor which has already been there.

[css-meeting-bot]

The Working Group just discussed Unknown fragment identifiers in @font-face src:.

The full IRC log of that discussion

<dael> Topic: Unknown fragment identifiers in @font-face src:
<dael> github: https://github.com//issues/2566
<gsnedders> I think Anne added it because Domenic drafted some text in HTML to better define what blocks the load event, including CSS.
<gsnedders> and Domenic said "it would be great if the CSSWG was able to resolve this one way or another, write the tests, and move the definition into one of their specs"
<dael> TabAtkins: Some fontface formats let you do special things with fragments. There might be more in the future. Question is how should we handle font URLs in fontface with unknown types of fragment identifiers.
<dael> TabAtkins: Initial suggestion was ignore, but I suggested do same as image function where if you see a fragment ID and don't know how to handle treat the URL as invalid. You don't know what the fragment is trying to do.
<dael> TabAtkins: Suggestion: we spec that for the fontface rule if a URL has a fragment identifier you don't know how to deal with you treat it as invalid.
<dael> myles: Not sure I agree. It seems in some situations you want to treat fragment as unknown and some others for whole is unknwonw.
<myles> my client crashed
<dael> TabAtkins: Browser that doesn't know what an open type collection is. Your fragment says load the second. Browsere tries to download but you don't know what will happen. Best situation is it see sa url that says to do something it doesn't understand best thing to do is to say I don't know what to do, skip it.
<dael> TabAtkins: I don't think doing something arbitrary can be argued as better for the user.
<dael> fantasai: Treating uninterpretable fragment IDs as invalid seems appropriate. It's just like if you got a URL with a theme you can't load you treat as invalid.
<fantasai> s/theme/scheme/
<dael> myles: TabAtkins said browsers that don't understand collections will ignore the whole ting, but I think all 4 browsers do understand collections
<dael> TabAtkins: Yes, it was a hypothetical example. I was using it as a stand in for a future where the fragment does something significant and you either load it and do someothing wrong or load it and have no idea how to deal with it so you wasted bandwidth.
<dael> myles: It sounds like there is a real discussion so we should maybe continue next week.
<dael> TabAtkins: I'm repeating from the thread so put your arguments in there.
<dael> Rossen_: Sounds like we won't get to consensus today. We'll take it up next week.

[upsuper]

src: url(SomeFont.otc#CondensedUltaSomething, CondensedUltaSomething.otf)

Also this syntax is probably not going to work anyway... You would need something like

src: url("SomeFont.otc#CondensedUltaSomething", CondensedUltaSomething.otf);