- From: Jonathan Kew <jfkthame@gmail.com>
- Date: Mon, 19 Oct 2015 09:58:58 +0100
- To: www-style@w3.org
On 19/10/15 09:22, Florian Rivoal wrote: > 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? I can understand the desire, but am unsure how practical this would turn out to be. What weight would be used for text that isn't covered by either my-favorite-font or my-fallback, where the browser has to go find some other fallback? Would it perhaps be simpler to allow font-weight to take a list of values, corresponding to the list of font-family names? So then you'd say body { font-family: my-favorite-font, my-fallback; font-weight: 400, 600; } strong { font-weight: 600, 800; } or something like that. We'd still need to define what happens when system fallback kicks in (I assume we'd use either the first or the last in the list), or if the lengths of the lists don't match (if the font-weight list is longer, extra values are dropped; if it's shorter, behave like the system fallback case?) The same thing could apply to font-stretch, presumably: body { font-family: my-favorite-font, my-fallback; /* where my-favorite is a rather condensed face */ font-stretch: normal, condensed; } HOWEVER, having said all that, I wonder if it'd be better to just use @font-face to construct a "virtual family" that handles the mappings you want: @font-face { font-family: my-favorite-font; font-weight: 400; src: url(MyFavorite.woff), url(MyFallback-Semibold.woff); } @font-face { font-family: my-favorite-font; font-weight: 600; src: url(MyFavoriteBold.woff), url(MyFallback-Extrabold.woff); } This allows you to collect whichever combinations of faces you like and map them to a given font-weight value for your virtual family. And adding unicode-range will allow you to optimize downloads and to manage more precisely what happens in areas of character coverage overlap. JK
Received on Monday, 19 October 2015 08:59:31 UTC