[css-fonts] Suggest allowing a list of font-family values in @font-face

[faceless2]

@font-face only allows a single value for the "font-family" entry, but I can't think of a reason that a list shouldn't be allowed here, and at times it could be useful.

An example: "NotoSans-Black.ttf" has two names in the OpenType name table: "Noto Sans" and "Noto Sans Blk". While best practice would be to define the Noto sans families like so:

@font-face {
    font-family: "Noto Sans";
    font-weight: 900;
    url(NotoSans-Black.ttf);
}
@font-face {
    font-family: "Noto Sans";
    font-weight: 400;
    url(NotoSans.ttf);
}

I can't think of any ambiguity that would arise if you could also do this:

@font-face {
    font-family: "Noto Sans", "Noto Sans Blk";
    font-weight: 900;
    url(NotoSans-Black.ttf);
}
@font-face {
    font-family: "Noto Sans";
    font-weight: 400;
    url(NotoSans.ttf);
}

This would be also useful if the font has names in several languages, eg "MS Mincho" and "ＭＳ 明朝". In fact that's probably a more compelling usecase, I should have opened with that really.

Finally, it's also an advantage when generating @font-face rules automatically from font files; there's no need to choose which of the several names an OpenType font is known by as the definitive one, you can just list all the appropriate entries.

[svgeesus]

So there have, since the earliest days of fonts on the wen in like 1996-7, two schools of thought on selecting fonts.

One is the 'DTP style' where for every piece of styled text, you select a specific face and you use the fully-qualified name there; it completely over-rides all aspects of any textual styling applied to any parent piece. So you would select, say, 18pt Helvetica Condensed Book Oblique. This works fine with unstructured or lightly-structured (DTP, word-processor) text and was especially popular when there were significant operating system limitations (like when Windows allowed a maximum of four faces in a family).

The other approach is structured: selecting a face selects a number of things (family, weight, style, size, etc) all of which may be individually overridden on a child element. This is needed when you have, say:

<p>Some text <b>some<i>more<span>text</span></i></p>

and the p is styled with Helvetica Book, the b inside that is Helvetica Bold, the i inside that is Helvetica Bold Oblique and the span changes the font family to Garamond, and you get Garamond Bold Italic.

Even in the CSS1 days, when condensed and expanded being in the same family was more hope than reality, and even when the Latin and the Cyrillic versions of a face were clearly in separate font files (because fonts had a max of 256 glyphs) this was the model adopted by CSS.

So the problem is not so much allowing Noto Sans Blk with a fully-specified font weight, as you have here; it is more when people override Helvetica Light with Noto Sans Blk, just changing the family name, and expect the weight etc to magically change along with it.

The point about matching on localized names is a separate issue, which I thought was already open, but I'm not finding it right now. I'm going to post this comment now anyway, before I forget.

[faceless2]

I knew I should have gone with the localization option. Much stronger argument :-)

I completely agree with everything you're saying.

But, there's an element of trying to protect the user from themselves here. Fonts sometimes have multiple names - localization is the obvious one, but there are undoubtedly others. Is it "ZapfChancery" or "Zapf Chancery"? "Courier" or "Courier New"? Why should I have to pick one?

Even without this change I can still do

@font-face {
    font-family: "Noto Sans Blk";
    font-weight: 900;
    url(NotoSans-Black.ttf);
}
@font-face {
    font-family: "Noto Sans";
    font-weight: 900;
    url(NotoSans-Black.ttf);
}

to reference the same font with two different names. What I'm proposing is - essentially - some syntactic sugar to make this unnecessary verbosity go away.

(edit: "Arial" or "Arial Unicode"? "Corsiva" or "Monotype Corsiva"? I'll stop now).

[Martin-Pitt]

Modern fonts might also be moving back to single fonts again due to variable fonts allowing much greater flexibility, this weakens the future use case slightly.

The localisation argument is strong and might have backing if we had more data on this.

Keep in mind that more complex font face families could lead to a lot of user mistakes. E.g. adding serif as a fallback, which means by font selection algorithm the other font families specify as alternatives in normal code when the custom font don't load would lead to serif being chosen first over any other alternative where that font was being used.

[AmeliaBR]

Another complication: you can have more than one @font-face rule with the same font-family name (and all other descriptors), which defines a composite font that uses the files specified in all those rules to get increased character coverage.

With multiple family name descriptors per rule, would all the @-rules need to use the same sequence? If not, you could conceivable have one generic fallback font for a lot of different family names, even though they have distinct primary font files. But, this would only work for combining font-face rules that differ by family name, and not by other descriptors, so I'm not sure how helpful this would be…?

[svgeesus]

Adding Agenda+ to see if there is any reason I shouldn't just add this.

[faceless2]

Ha, I'd completely forgotten about this one - didn't even recognise it as one of mine at first.

I still can't see any reason why multiple families aren't allowed, and given the syntax would essentially be identical to multiple @font-face blocks, it's not going to break anything - it feels unlikely that someone, somewhere, is relying on a currently invalid @font-face with multiple families remaining invalid.

But I'm struggling to see a huge benefit either, if I'm honest - I just don't know how often this comes up in the real world. If there's an l10n argument for it, I'm pretty confident I'm not the one to make it. Will leave to your discretion Chris, but if you want to close (as "Commenter Apathetic"?) I'm fine with that.

[css-meeting-bot]

The CSS Working Group just discussed [css-fonts] Suggest allowing a list of font-family values in @font-face #3691.

The full IRC log of that discussion

<dael> Topic: [css-fonts] Suggest allowing a list of font-family values in @font-face #3691
<dael> github: https://github.com//issues/3691
<dael> mike: I couldn't see a reason not to
<dael> mike: It expands to multiple fontface blocks. Not sold on need for it, but struck me as a why not. I think chris is trying to clear issues
<dael> myles: I think emilio brought up a problem with it.
<fantasai> s/emilio/Amelia/
<emilio> s/emilio/Amelia
<dael> TabAtkins: Problem is same as if you do multiple font faces still. Possibly not what author intends, but well defined what would happen
<dael> TabAtkins: You can define multiple faces that are identical except name
<dael> myles: if 2 font face blocks, one with a one with a,b should they be combined together
<dael> TabAtkins: SHould be exactly as if a,b was to separate faces
<dael> AmeliaBR: One related question si will this only apply to font family name or other descriptors
<dael> mike: Only intended name. Easiest to leave at that
<dael> AmeliaBR: I think the example of something like a black font which is sometimes referred to with black or as 900 weight generic is a good example
<dael> AmeliaBR: Question for me if it's sensible syntax
<dael> myles: mike said it's a why not instead of use case. If this is valuable you would see authors having to duplicate and I don't see it on the web
<dael> mike: That's there I got to as well
<dael> AmeliaBR: Sounds like we lean no change?
<dael> mike: If there's an argument against change or change sake that's it. Might be a localization argument to give fonts Japanese and English name. I'm not qualified for that.
<dael> florian: This is just syntaxtic sugar for repeating
<dael> fantasai: So unless we see that no good reason to change
<dael> florian: Is there acss preprocessor that does it?
<dael> mike: not that I know of
<dael> Rossen_: Than let's hold now and come back if there's use cases
<dael> myles: Let's close it.

[jpamental]

Just missed commenting before discussion, but I'm struggling to see the real value other than perhaps localization (or is that localisation?) and the only place that would really come into play is if the font family names are being picked up and displayed in a CMS. Otherwise, the font-face declarations are being set by the same people writing the CSS, so the value in the flexibility is perhaps a bit more limited.

All in all, seems a lesser priority.

[faceless2]

All in all, seems a lesser priority.

I think that was the conclusion. Someone mentioned they were going to close it, not done yet so I will