RE: [css-fonts] font-weight-adjust

I am not sure if having a universal "font-weight-adjustment" hammer is a good idea. 

Even though some cars may come with a tool set that allows you to change wheels - none of them include tools that one would need to do an engine maintenance. The reason for it is that some things are simply meant to not be messed with by users and should be left to experienced professionals. 

Font weight differences are not there by accident, font designers pay a great deal of attention to legibility and text color and contrast (significantly influenced by stem weights) are important aspects of consideration. Making adjustments to the weights of e.g. vertical stems of two different fonts may greatly affect legibility of one or both of them and I would argue that if two fonts are used that do not play well with each other it manifests bad typographic design choices that simply need to be revisited.

In general, I think that adopting a design approach where font choices are compatible is better than using a hammer to make quick adjustments. in the vast majority of cases, if one's only  tool available is a hammer - every screw looks like a nail! I'd rather not give them hammer for this reason alone. And, in the world where webfonts give authors full control over their font choices, there is no excuse to bad design choices that require adjustments.

Thank you,
Vlad


-----Original Message-----
From: Florian Rivoal [mailto:florian@rivoal.net] 
Sent: Monday, October 19, 2015 4:22 AM
To: www-style list
Subject: [css-fonts] font-weight-adjust

With the same font-size, the apparent size of the text varies depending on the actual fonts used, and we have font-size-adjust to deal with that.

However, the same is true about font-weight, and we don't have a way to cope. Font-weights numbers are merely relative to each other within a font family. Just because two fonts both support the same numerical values for font-weight does not mean the stroke width and perceived thickness will be the same. Conversely, even if both font families have weights where they visually match each other, there is no guarantee that they will map these to the same numerical value.

Based on this, I suggest that a font-weight-adjust property, analogue to font-size-adjust property, would be a useful addition.

Sample use case, based on a real situation at encountered at Bloomberg:

You have a custom font, which you really like, and use for your body text. Its normal/400 font weight is somewhat thick (and its heavier weights are thicker). The fonts support a good chunk of unicode, but not all of it, so you have a fallback font to deal with the rest. The fallback isn't as nice, but but it's not practical to commission someone to make one that covers every language you need to support, and you've found a generic font that looks acceptable. However, this font (which also supports multiple weights) looks thinner than your favorite one at normal/400, so if you display chunks of text which rely on both fonts, such as CJK text (thin fallabck) with latin numerals (thick base font), it looks bad. The fallback font's 600 would be a better match for the base font's 400.

Using this:
  body {
    font-family: my-favorite-font, my-fallback;
    font-weight: 600;
  }
does not not solve it, since it also base the base font thicker, and the weight gap remains. So you'd like to say something like:
  body {
    font-family: my-favorite-font, my-fallback;

    font-weight-adjust: 400 to 600 / 600 to 800;

    /* imaginary syntax saying that for the fallback font,
    the UA should use the 600 (resp. 800) weight when 400
    (resp. 600)is specified.*/
  }
  strong {
    font-weight: 600; /* makes the base font 600, and the fallback 800 */
  }

Unlike font-size-adjust, I don't think we can use a multiplicative (or for that matter additive) factor, since font-weights, despite looking like numbers, are not something you can do arithmetic on, which is why I'm providing an explicit mapping.

Syntax aside (yeah, bikesheding ahead), does that make sense? If not, why not?

 - Florian

Received on Monday, 19 October 2015 09:10:04 UTC