[css-fonts] Specifying changes to parameters for fallback fonts

After another session of fruitless wrestling with fonts, i thought i should make sure (a) i'm not missing something obvious, and (b) if not, ask whether we can improve CSS.

This time i was trying to get a particular look across Mac- and Windows-based browsers. On the Mac i like the look of Helvetica Neue with font-weight set to 300 at a font size of 16px. But i can't find anything to match that in Windows standard fonts – well, i could get reasonably close, but i'd need to be able to change the font weight and the font size for a font-family name specified as a fallback.

I've never understood why, in CSS, i can't say something like

p {
	font: 'macfontname' 300 16px, 'windowsfontname' 500 18px, sans-serif;
}

This is a much bigger problem in non-Latin scripts, where glyph dimensions can vary widely from font to font at the same font-size. For example, compare the same glyphs set to the exact same font-size in Mongolian Baiti and Noto Sans Mongolian:

It's not just mongolian, this is a constant problem in arabic, and many other scripts.

And by the way, i thought about web fonts, but i can't help thinking that you should be able to just use standard platform fonts if you want to. Note that that tweaking the size/weight of such fonts would be easier than finding fonts that look good and can be used for free to cover the up to 15 languages we have on the i18n site, but also we're often dealing with multiple languages on a given page for examples etc, which also ramps up the bandwidth when using webfonts.

What am i missing?

I fully agree with Richard. Actually, when I saw his comment, I said to myself: How obvious; why haven't I thought about this much earlier. Combining multiple scripts on a page always requires a lot of care with respect to size and also weight.
This functionality would actually also be very helpful for combining multiple fonts covering the same script. I have seen many cases where e.g. a monospace font for some program text didn't fit well with a proportional font used for the running text.
The only reason that I was able to think of for why we haven't thought of such a feature until now is that with low-resolution displays, such adjustments din't work very well. But with today's high-resolution screens, they are easily possible (and all the more desirable).

@font-face

I agree with the problem statement, it's definitely valid. But there are some issues with the proposed solution:

it makes font-size a list-valued property, which is a change we could make but still something new.
BUT, the font-size ratio between fonts is probably constant across sizes, so having to write out a whole list of font-sizes every time you want to change the size of an element is a lot of wasted work (and makes the default HTML styles hostile; use your font in an <h2> or <small> and it gets messed up unless you specifically override it). You instead probably want a list-valued font-size-ratio property.
BUT there's no way to line that up with the fallback font, which displays at some unknown size relative to the other fonts
ALSO, font-size isn't the only thing you want to control; I've heard people want to coordinate weight or spacing between different fonts to get a consistent look.

The third point is probably unaddressable and we just need to leave it; that's just a fallback issue anyway and shouldn't get hit by well-designed content in normal circumstances. The rest, tho, suggest that the solution is higher than the property level and probably needs to be addressed either thru @font-face, or a new at-rule better suited for constructing a composite fallback-list with control over all the aspects at each point.

My biggest worry is about how this new syntax would interact with the existing font-weight and font-size properties. It seems very confusing to have two properties which may disagree.

I do agree that the current facilities for font fallback are lacking.

@tabatkins

It seems we're all agreed on the problem statement, and that a solution needs to be found.

To be clear, I have no attachment at all to the syntax of the example solution i included in my original post (and btw @tabatkins the 300 and 500 were meant to be weights). I just want some way to indicate that various parameters should be different as you fall back to one of the named fonts.

I think that once you get to sans-serif all bets are off. It's just a question of specifying comparative parameters for the named font families in the fallback list.

I also suspect that the alternative parameters could be specified comparatively against the first item in the list of font-family fonts, or you could have some special rule which allows you to specify absolute font sizes (for example) and that then works out the ratios for you.

I guess @font-face might be the right way to go. Probably a new descriptor e.g. font-size-ratio can be added into @font-face to address the font size problem.

I think weight difference is already resolvable via @font-face as you can specify full font name or postscript name in local().

This could be annoying for authors, though.

i gave some thought to @font-face yesterday, and concluded that actually it does the reverse to what we want. With @font-face you specify features and it selects a font on that basis, whereas for this we want to specify a font and then select features.

I suspected that maybe we need a new at-rule such as @fallback-font-sequence which allows you to specify a number of local or embedded fonts, associate them with each other, but then establish appropriate distinctions between their features. Then the @fallback-font-sequence could be given a name, which is used in the font-family property value. (?)

I was considering the idea of allowing font-weight and font-size to take a new value which would represent a normalized weight / size. Given that we're only concerned about preinstalled fonts here, the UA would likely have the information required to perform such a normalization. This would be much simpler than introducing a new at-rule.

@r12a

Yeah, changing @font-face is the wrong way. What you described, @r12a, is what I was thinking of.

No need to reach for mongolian, the same happens just fine in English. Baskerville as found on OS X vs Libre Baskerville, at the same font size and same weight, are very differently sized.

I've found myself wanting to use the OS X one as a default (it's got more open type features), and the libre one as a fallback, but the size being very different makes it tricky, and font-size-adjust cannot be used to adjust only some of the fallback fonts.

Gérard said:

Florian,

Can you explain why you believe that 'font-size-adjust' can not be used to adjust (compensate) fallback fonts. I am not sure I understand what you are saying.

3.6 Relative sizing: the font-size-adjust property
https://www.w3.org/TR/css-fonts-3/#font-size-adjust-prop

In my mind, 'font-size-adjust' has been created specifically so that a fallback font (not available on a system) used size will be adjusted to match the first font of a list or to constrain all possible match of a font list to a certain size.

The glyphs will likely/possibly/probably not look the same but their relative size (aspect value) will be the same, must be the same:

http://test.csswg.org/suites/css-fonts-3_dev/nightly-unstable/html/font-size-adjust-003.htm

Sorry, I was taking shortcuts and not explaining them well. font-size-adjust does indeed work, but it merely does the objectively thing, not the subjectively correct things.

The number you need to use for two fonts to feel the same size isn't always the same.

For instance, if you look at this example, preferably on a Mac, or on a computer that has a baskerville font with the same metrics installed:
http://jsbin.com/powokig/edit?html,css,output

For those who don't have the right fonts it looks like this

The first p has not font-size-adjust, and is obviously terrible.

The second one has font-size-adjust applied with the same value on both baskerville and libre baskerville. It's much better, but the two fonts, while close, don't feel quite the same. Libre Baskerville has comparatively shorter capitals, and due to the shape of the glyphs, the lower case letters feels every so slightly shorter as well, even if I am sure the metrics do match.

On the third p, I am applying a different font-size-adjust for baskerville and libre baskerville, which I think makes them subjectively more similar. I can do this here because I am actually specifying the fonts separately, but if I had been using fallback fonts, there would be no way for me to do that.

In this case, the difference is tiny, and nothing to loose sleep over, but the best result isn't the one you can achieve with font-size-adjust, and I suspect that as Richard mentioned, things get worse with internationalization.

One difficulty here is that there is no way in CSS to say whose version of a font with a given name you want. In most cases all Baskerville fonts are the same - but what if there's one with pictures of dogs in it? Traditionally the font vendor would be named, e.g. Adobe Baskerville, and often these days include vendor names in the font name, but for example on my system I have 228 variants of Helvetica, many installed by different programs. The per-glyph fallback on a site that uses Helvetica means I start with a randomy-chosen Helvetica, then might get e.g. fi ligatures from a different one. I quite often see Web sites with the fi/fl/ff ligatures obviously in a different font, for example bolder when the font names didn't fit into the CSS 100-step boldness categories.

So there are several steps,
(1) choosing a base font family, which as Tab says needs some high-level work, e.g. to choose the first font family from a list, where that family has fonts to support roman and italic for a given character range along with specific other features, such as having a condensed variant, or having true small capitals;
(2) choosing a base font within that font family, without wandering off into some unrelated font that happens to have the same font name but came from a different vendor or foundry
(3) potentially modifying that chosen font, e.g. to simulate bold or oblique (ugh but there we go) or to condense or stretch it (some implementations do this if font-stretch is specified; others will only select a font that already exists with a corresponding font matrix (!) and at least one will simply leave blank gaps in the output where hte text shold be if font-stretch doesn't match)
(4) per-character and per-glyph fallback as needed, going back to step (2) and then repeating step (3).

Right now CSS fonts doesn't seem to give clear control over these steps, leading to some odd effects such as those you (Richard) see.

Selecting based on platform is not the right approach though - e.g. Richard left out Linux or Android, and desktop macs have different fonts perhaps than iphones, as do differing versions of Microsoft Windows. And many users have fonts that are from different platforms, whether from dual booting or (probably much more often) from installing applications that in turn installed fonts. The test should be for specific versions of fonts, or at the least specific foundries an capabilities (just like writing portable C or C++ tests for features, not for platform).

On 2016/05/29 11:11, Liam Quin wrote: Selecting based on platform is not the right approach though - e.g. Richard left out Linux or Android, and desktop macs have different fonts perhaps than iphones, as do differing versions of Microsoft Windows. And many users have fonts that are from different platforms, whether from dual booting or (probably much more often) from installing applications that in turn installed fonts. The test should be for specific versions of fonts, or at the least specific foundries an capabilities (just like writing portable C or C++ tests for features, not for platform).

I have only a vague recollection, but doesn't the X11 windowing system have information such as foundry,...? I don't think we can use that system as is, but maybe we get some additional hints out of it. Regards, Martin.

@litherum

@litherum With regard to:

font-size (low priority, since we already have font-size-adjust)

I'm not sure font-size-adjust really covers this, especially for non-Latin fonts where the concept of ex-height may not be at all well defined, and there's a good chance that whatever data may be in fonts won't be appropriate to harmonize across families.

So to take @r12a's example of Mongolian, I imagine an author might want to write something like (using a hypothetical font-size-override descriptor):

@font-face {
    font-family: AdjustedBaiti;
    src: local("MongolianBaiti");
    font-size-override: 125%;
}
@font-face {
    font-family: AdjustedNotoMongolian;
    src: local("NotoSansMongolian");
    font-size-override: 75%;
}

body { font-family: AdjustedBaiti, AdjustedMongolian, serif; }

and this would use Baiti if available, enlarged to 125% of the computed font-size; or else Noto, reduced to 75%; or if neither of these are present, you'd end up with whatever serif maps to or whatever fallback finds.

font-size-adjust doesn't feel like the right tool for this, given its very specific (and Latin-oriented) definition. I suppose in theory if it were a descriptor, it would be possible to determine a font-size-adjust value for each @font-face rule that would yield the desired size relationship, but it feels really awkward.

(Maybe a solution would be an ex-height descriptor, so that you could specify an arbitrary value for a given face, to get control of what font-size-adjust will do for it even if it's a non-Latin script with no inherent "ex-height" and where the value in the font resource itself may be meaningless. Still feels like a cumbersome way to go about things, though.)

On Wed, 2021-02-10 at 11:01 -0800, jfkthame wrote: [...]

body { font-family: AdjustedBaiti, AdjustedMongolian, serif; } and this would use Baiti if available, enlarged to 125% of the computed `font-size`; or else Noto, reduced to 75%; or if neither of these are present, you'd end up with whatever `serif` maps to or whatever fallback finds.

More precisely, that would be done on a per-character basis, so if there's a character in the 2nd but not the 1st font, and the rest are available in the 1st, you get a mix. I'm not sure that anything could be done better, except that you may very well want (or need) different fallback fonts depeing on the font chosen. There's also no way with font-face to say, if Helvetica was chosen for the regular font in this element, use Helvetica-oblique as the italic font, and if Helevetica-Oblique is not available, use serif as the font for p, not Helvetica at all. So i think i'd prefer to see a @font-family() or @font-set() that can have a use-when: all-available property. That way multilingual documents have a much better chance of working. I don't think that affects Richard's original use case, though. Part of what's going on here is the need to control the relationship between selecting a font and modifying text properties -- font-size, whether small caps, whether italic, colour, letter-spacing, maybe even font-stretch -- based on the selection.

…

-- Liam Quin, https://www.delightfulcomputing.com/ Available for XML/Document/Information Architecture/XSLT/ XSL/XQuery/Web/Text Processing/A11Y training, work & consulting. Barefoot Web-slave, antique illustrations: http://www.fromoldbooks.org

I'm not sure font-size-adjust really covers this, especially for non-Latin fonts where the concept of ex-height may not be at all well defined, and there's a good chance that whatever data may be in fonts won't be appropriate to harmonize across families.

I agree. font-size-adjust was designed (in, like, 1997, by Todd Fahrner) for Latin, and also works with Cyrillic and Greek scripts. If you want to harmonize two fonts sizes for Arabic, or Hebrew, or Devanagari, then (best case) it has no benefit and (worst case) it adds irrelevant, random re-scaling which may make things worse..

@r12a

@r12a wrote:

the use cases in your new issues @litherum seem to completely ignore the original use case for this issue, which i repeated a couple of comments back. It's not only about tweaking the look of fallback fonts while web fonts are loading; it's also about setting different sizes, weights, etc depending on which system font the browser is going to use.

I think I captured this in this comment on the new font-size issue

If that is correct I can add that third use case to the other new issues spawned from this one.

@svgeesus

Thanks, @svgeesus. I think i'd have written:

Being able to tweak the look of any font in the font stack where the fonts in the stack have very different visual sizes or other metrics.

Removing the mention of fallback, for me, makes the rules less rigid about which font(s) in the stack get the adjustment, and allows you to move fonts around in the stack as you wish, later. I think we're looking for a scenario here where the adjustments are applied to a font to fit a context, rather than to match the first font in the stack (though that's a subtle difference). It also makes the example that @jfkthame provided at #126 (comment) work.

I removed 'for the script being rendered' because, on reflection, this adjustment could be just as useful for, say, a situation where you want to specify an Arabic font with no Latin glyphs and a Latin font such that they look as if they match in a single piece of Arabic text containing Latin acronyms or names. This is a frequent issue for me in Arabic (naskh and nastaliq styles), as well as for other scripts.

@r12a

@r12a

@litherum could you, or somebody, give an example of what the syntax may look like

Given your example:

p {
	font: 'macfontname' 300 16px, 'windowsfontname' 500 18px, sans-serif;
}

It would look something like this:

@font-face {
    font-family: 'macfontname';
    font-weight: 300;
    font-size-override: 100%; /* not actually necessary, but included for explicitness */
    src: local("macfontname-300weight");
}

@font-face {
    font-family: 'windowsfontname';
    font-weight: 300; /* this is intentionally *not* "500" */
    font-size-override: 112.5%;
    src: local("windowsfontname-500weight"); /* *this* is where you specify you want weight 500 to be rendered */
}

...

p {
	font: 300 16px 'macfontname', 'windowsfontname', sans-serif;
}

@litherum

Thanks, @litherum. I thought that the existing descriptors in @font-face such as font-weight are for matching/finding fonts, rather than modifying them. Could easily be that i'm wrong? I would have expected to see something similar to font-size-override, let's call it font-weight-override to actually apply modifications to the incoming font. (So you might have both font-weight and font-weight-override in the list of descriptors.)

The value for font-weight-override would presumably be a numeric offset, such as +100, or -200, or so on? Or maybe (?) something like bolder, which i think is currently not allowed for @font-face descriptors.

With that arrangement i think you wouldn't need to add stuff to the local() argument, which i think is cleaner - you'd just have the font name, as usual. In addition, it seems odd to modify the font weight in local("windowsfontname-500weight") but to modify the font size in font-size-override.

does that make sense?

So i guess i was expecting something like this:

@font-face {
    font-family: 'harmonisedMacfontname';
    src: local("macfontname");
    font-weight: 300;
    font-size-override: 100%;
    font-weight-override: +100 /* not necessarily needed, but could perhaps be useful */
}

@font-face {
    font-family: 'harmonisedWindowsfontname';
    src: local("windowsfontname"); 
    font-weight: 300;
    font-size-override: 112.5%;
    font-weight-override: -100;  /* of course, only needed if the font comparison merits it */
}

...

p {
	font: 300 16px 'macfontname', 'windowsfontname', sans-serif;
}

@font-face

I thought that the existing descriptors in @font-face such as font-weight are for matching/finding fonts, rather than modifying them.

These descriptors define the characteristics of a font face and are used in the process of matching styles to specific faces.

So yes, the descriptors are used for matching against - the properties (requests for styling) are matched against the descriptors (descriptions of the fonts that are available).

The descriptors typically contain values extracted from the font; but they need not do so. And the font is not automatically opened and checked against the descriptors, if that is what you were thinking.

So for example the font family name is usually the same as what the font contains - but it need not be. It is common to make the name shorter for example. And it can be something different entirely.

And the font weight is typically what the font says it is, but (for non-variable fonts) could be set to anything. I could point to a heavy, ultrabold font which is weight 800 and have the descriptor say it is weight 200, for example (not very useful, but possible). More usefully I could decide that this particular font looks heavier than it claims to be, so I could set the font-weight descriptor to 830 instead.

An issue is that, while massaging (or lying about, as some prefer to say) non-variable fonts is easy, it becomes harder for variable fonts because we are trusting the font more. A variable font with a weight axis may cover, say the range 200 to 500. I can massage this by using a font-weight descriptor of 280 500, meaning I don't want it to match for weights below 280; but if it does match, there is no way for me to say "given a weight n, ask this font for weight a + n * b.

@font-face

Or maybe (?) something like bolder, which i think is currently not allowed for @font-face descriptors.

Correct, it is not: auto | <font-weight-absolute> <font-weight-absolute>?

because bolder would not be describing anything (bolder than what?) so is unsuitable for a descriptor.

On the other hand bolder is fine as a property value (make this bolder than the parent, please)

One issue with doing this all via descriptors even for local fonts is that @font-face is for single faces (let's leave variable fonts out for now). So, if I want to declare e.g. that if Helvetica Neue is used, I want tighter letter-spacing, I would need to declare dozens of rules, one for each Helvetica Neue face. Even just scoping it to Helvetica Neue Bold still requires several rules, especially if there are condensed and expanded faces available etc.

Also, the way matching is done in the font-family property is not the same as in the local() function. The latter requires the locally installed name, which can vary a lot, even for the same font.

This is why I tried to suggest in #126 (comment) that the place for these descriptors is in a new @-rule that addresses the family rather than the individual face. This would provide a customizable mapping from the "nominal" property values as used in the CSS to adjusted values that should be used with the specific family.

The only way I think it will be really usable for the case that I was describing is on the selector level: meaning a specific font and usage needs this 'fallback correction' for one or more fallback font. I don't think this is helpful enough on a font family as you would need different corrections for different weights of a font (or variant in the case of italics), and applying the same correction for all uses of a single font across all selectors doesn't help either if you are using a bold weight with negative letter-spacing in a header and normal spacing with adjustments for fallbacks in body copy.

[css-fonts-5] Start level 5 as CSSWG resolved to put stuff there today …

Related: Font styles & font fallback

This also applies to font-feature-settings: my main font has about a dozen of them enabled, but one of them makes FreeSerif (far down in the fallback list) look like ape…

Navigation Menu

Repository navigation

[css-fonts] Specifying changes to parameters for fallback fonts #126

52 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[css-fonts] Specifying changes to parameters for fallback fonts #126

Description

Activity

duerst commented on May 22, 2016

tabatkins commented on May 23, 2016

litherum commented on May 24, 2016

r12a commented on May 24, 2016

upsuper commented on May 24, 2016

r12a commented on May 25, 2016

litherum commented on May 25, 2016

tabatkins commented on May 25, 2016

frivoal commented on May 26, 2016

frivoal commented on May 26, 2016

frivoal commented on May 26, 2016

liamquin commented on May 29, 2016

duerst commented on May 30, 2016

52 remaining items

jfkthame commented on Feb 10, 2021

liamquin commented on Feb 10, 2021

svgeesus commented on Feb 11, 2021

svgeesus commented on Feb 11, 2021

r12a commented on Feb 11, 2021

litherum commented on Feb 12, 2021

r12a commented on Feb 12, 2021

svgeesus commented on Feb 12, 2021

svgeesus commented on Feb 12, 2021

LeaVerou commented on Feb 12, 2021

jfkthame commented on Feb 12, 2021

jpamental commented on Feb 12, 2021

svgeesus commented on Oct 31, 2022

mirabilos commented on Oct 19, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions