Re: bolder/lighter defintion

>> The solution to this problem I proposed at the last F2F was to replace
>> the bolder/lighter definitions with a simple mapping that's independent
>> of the font family in use.  It's equivalent to running the existing font
>> matching algorithm using a family with weights 100, 400, 700 and 900.

[SZ] This mapping avoids having the computed value depend on the font(s)
[SZ] in use at the point where the relative value is used to change the font
[SZ] weight. It is equivalent to always choosing the computed value to be the
[SZ] next higher or lower weight in an artificial font family with weights
[SZ] 100, 400, 700 and 900. The chosen computed weight is then used in the
[SZ] font matching algorithm with the fonts actually in use to find the
[SZ] weight that best matches the computed weight as already defined in the
[SZ] specification. For most fonts, this will produce a font weight that most
[SZ] often matches the authors expectations and the rules for resolving a
[SZ] sequence of "bolder"s and "lighter"s are simple to understand.

I think we're saying the same thing.  But "it is equivalent to always
choosing the computed value to be the next higher or lower weight in an
artificial font family..." is not quite right.  For example, if the
parent element has font-weight set to 600 and the child element is
bolder, the "next higher" weight face is actually 900, since 600 maps to
700 in this family.  The inherited weight is first mapped to a weight
that exists in the family, *then* the next higher weight is chosen.

Here's a visual representation of this:

http://people.mozilla.org/~jdaggett/bolderlightermappings.png

John

Received on Tuesday, 19 May 2009 00:57:23 UTC