-
Notifications
You must be signed in to change notification settings - Fork 642
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[css-fonts] Suggest allowing a list of font-family values in @font-face #3691
Comments
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, 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:
and the 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 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. |
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
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). |
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. |
Another complication: you can have more than one 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…? |
Adding Agenda+ to see if there is any reason I shouldn't just add this. |
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 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. |
The CSS Working Group just discussed 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. |
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. |
I think that was the conclusion. Someone mentioned they were going to close it, not done yet so I will |
@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:
I can't think of any ambiguity that would arise if you could also do this:
This would be also useful if the font has names in several languages, eg "MS Mincho" and "MS 明朝". 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.
The text was updated successfully, but these errors were encountered: