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).

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.

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.

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).

@liamquin In WebKit, we are interested in limiting font selection of local font faces to only the preinstalled fonts (disregarding any user-installed fonts). Originally, the purpose of this idea is to combat fingerprinting, but it also sounds like such a policy would also solve your item (2). However, we're still investigating this idea; we don't know yet if it will work.

It sounds like using something like @fallback-font-sequence would associate a small set of CSS properties with each item in the font family list, where it is obvious how to apply each property in that small set to individual glyphs rather than full elements.

In the related issue #450 (comment) we are investigating using this mechanism to better match fallback fonts to web fonts during the download of the web font. A small set of properties suggested are:
font-weight
font-size
letter-spacing
word-spacing
line-height

One thing we should consider is that, if these properties are all bundled up together into an at-rule, they don't cascade nicely. This means that if a web author wants to use an existing @fallback-font-sequence rule in a new context, but slightly modified, they would have to create a copy of the whole rule, including all the properties inside it.

In this model, we would also have to define the priority for the CSS properties inside the @fallback-font-sequence rule. Because there are no selectors, we would have to define what to do if the element already has those properties set.

• Perhaps the computed style of that property on the element is ignored for glyphs using fallback fonts.
• Or, perhaps we only allow relative values (like percentages) in these properties and resolve those percentages against the element's computed style. (This would require modifying the spec for letter-spacing because it currently only accepts a length.)

Is this something we'll ever get to see in CSS?

The CSS Working Group just discussed Specifying changes to parameters for fallback fonts, and agreed to the following:

• RESOLVED: Solve the general case of fallback font adjustment via @font-face descriptors
• RESOLVED: Add advance-override descriptor to Fonts 5, precise details TBD

As an aside, I'm not really convinced it's worthwhile to try and refine this stuff to such a degree. Fallbacks are just that: fallbacks. They may or may not even be available on a given user's system; you might end up with some other default/generic anyway. They aren't expected to render identically to the target webfont, no matter how many knobs we provide to tweak them.

What follows may be a slightly philosophical point.

I'm glad to see how the ideas here can also be applied to fallbacks related to web fonts, etc. I just didn't want to lose sight of my original problem, which was: There are very few Mongolian fonts, but pages on Windows will have guaranteed access to Mongolian Baiti, and pages on OS X will not have access to Baiti but will have access to Noto Sans Mongolian. The problem being that the metrics of these fonts on display are very different. So i just wanted a simple way to be able to say: If the browser is using Baiti, use these additional settings for font size, density, etc; if the browser is using Noto, use these other settings. So it's a use case that doesn't attempt to make the font look alike, but does attempt to produce something that takes up the same amount of space and works well for readability. In this sense, this is a slightly different kind of 'fallback' behaviour in that you actually pretty much know which font is likely to be used in which case. Solving that issue will be very useful for working with non-Latin fonts.

@r12a I'm completely in agreement with you!

My use case is essentially the same: I want to make sure that the type fits in the same space to avoid reflow or massive amounts of repaint. Having it look the same (mimicking x-height for example) is not really important to me. I just want things to stay in the same place so if no web fonts show up, the integrity of the design/layout is maintained. And if they do eventually show up, nothing moves around.

In this way, both circumstances benefit!

A solution that utilizes @font-face descriptors isn't just for web fonts - @font-face blocks can use src: local(...) to represent local fonts, too.

Alright, I've broken up this issue into individual pieces, as per the discussion at the F2F:

• font-weight (low priority, since we already have a solution for non-variable fonts)
• font-stretch (low priority, since we already have a solution for non-variable fonts)
• font-size (low priority, since we already have font-size-adjust)
• word-spacing
• I think letter-spacing is already covered by [css-fonts] Reduce layout shift via @font-face descriptor(s) overriding inline spacing  #5533
• I think line-height is probably covered by ascent-override, descent-override, and line-gap-override

Now that I think about it, I suppose can probably close this issue in favor of those other, more narrow issues

Wait a sec – 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 read the transcript from the session yesterday, but i can't say i understand what the actual proposal is other than that it will be done via @font-face descriptors.

@literum could you, or somebody, give an example of what the syntax may look like (approximately/grosso modo) if one wants to resolve, say, the Mongolian issue i described above?

@r12a Not sure how well that was minuted but I made that exact point in the call and was told that system fonts should also be declared via an @font-face rule (and local()).

@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.)

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 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.

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

@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;
}

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;
}

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.

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.

Related: Font styles & font fallback