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

On Fri, Oct 23, 2015 at 12:48 AM, Florian Rivoal <florian@rivoal.net> wrote:
>> On 23 Oct 2015, at 16:10, John Daggett <jdaggett@mozilla.com> wrote:
>> Type is typically used in some form of hierarchy within a page. For example, headings using a "branded" display face, body text using a commonly available platform font. Sites that display content in different languages need to make font choices per language to maintain a consistent typographic voice across locales. Universal fontlists are a poor way of addressing that.
>>
>> In short, I don't think your 'font-weight-adjust' proposal is a good or needed solution.
>
> I'm perfectly willing to admit it is a poor solution, but I don't quite see why this is any less useful to solve than text-size-adjust.

Because font-weight-adjust is a single value, that can be applied
reasonably to all fonts in a mechanical fashion, to achieve pretty
close to the desired effect. It's not perfect in all cases, but it
does pretty good at what it's intended to do.

The proposed 'font-weight-adjust' does not have these properties.  It
can't be applied mechanically, as the appropriate "weight" is a visual
matter, so it can't be boiled down to a single number.  The page
author has to specifically choose the correct weight for each
font-face to get a visual match, and that means aligning a list of
weights to a list of fonts.  This hasn't been done before for fonts -
of all the font properties, only font-family is list-valued.  It also
has unique difficulties that other list-valued properties don't have,
since its is guaranteed to have one or two entries on it beyond what
you specified - a default font, and a last resort font, neither of
which you have control over, or can apply font-weight-adjust to.

Another interesting point - I don't think we've used coordinated lists
for any inherited properties before.  That's intentional, because they
need to *coordinate*. If you change the value of one of them but
forget to change the other, the other will inherit a now-meaningless
set of values, and create a messed-up display.  This is possible in
non-inherited properties too, but somewhat more difficult since you
have to explicitly set values on only one of the properties and have
them clash with another explicit set of values from a different rule.
Plus, we usually make the shorthand list-valued and capable of
specifying all the values together anyway, so in the common case you
reset everything by default.  We can't easily do that in 'font',
though, because of how messed up the shorthand is.

Also, this is one more piece of font-related information that has to
be spammed all over the page wherever necessary. Authors already
dislike having to copy/paste  and maintain long font-family lists, as
it's very error-prone and hard to maintain.

As noted previously by John, using @font-face to construct a synthetic
font has none of these problems.  You pick out the specific faces you
want for a given weight, listing them in fallback-precedence order.
You can then use the one single font in font-family, and specify a
single desired and appropriate font-weight for the situation.  It does
one better, actually - you can match up font-style and font-stretch,
too, if desired.  This lets you avoid having to sync up list-valued
properties, avoids dealing with troublesome inheritance, avoids even
having to produce long font-family lists in the first place.

It's definitely more work than a quick font-weight-adjust hack (or a
list-valued font-weight, like John suggested), but it's the
technically better solution by a long shot, in my opinion.

~TJ

Received on Tuesday, 8 December 2015 22:22:13 UTC