Re: bolder/lighter defintion

On 05/18/2009 07:00 AM, John Daggett wrote:
>
> 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.
>
> This is my proposed wording:
>
>>
>> Values of 'bolder' and 'lighter' indicate values relative to the weight
>> of the parent element.  Based on the inherited weight value, the weight
>> used is calculated using the chart below.  Child elements inherit the
>> calculated weight, not a value of 'bolder' or 'lighter'.
>>
>>    Inherited value   bolder  lighter
>>    100               400     100
>>    200               400     100
>>    300               400     100
>>    400               700     100
>>    500               700     100
>>    600               900     400
>>    700               900     400
>>    800               900     700
>>    900               900     700
>>
>> The table above is equivalent to selecting the next relative bolder or
>> lighter face, given a font family containing normal and bold faces along
>> with a thin and a heavy face. Authors who desire finer control over the
>> exact weight values used for a given element should use numerical values
>> instead of relative weights.
>>
>
> For situations where only two weights exist, normal and bold, this will
> lead to the same behavior as the previous definitions, with the exception
> of the behavior in complicated nested elements that we've discussed
> before.  It results in a computed weight that is a valid weight.  For
> fonts with several weights it separates those into clearly distinct
> levels, ones with a perceivable difference in weight (e.g. jumping from
> normal to medium isn't as clear as normal to bold).

The problem with this proposal is that it doesn't roundtrip very well.
If I start at 300 and go bolder, then lighter, I don't get back to my
start: I get 100 instead of 300. The same is true of many other start
points. It might not make a difference in a font with few weights,
but in a font with all weights available, it's likely to be noticeable.

There are some hole-filling rules in the font-weight section of CSS2.1:

   # If there are fewer then 9 weights in the family, the default
   # algorithm for filling the "holes" is as follows. If '500' is
   # unassigned, it will be assigned the same font as '400'. If any
   # of the values '600', '700', '800' or '900' remains unassigned,
   # they are assigned to the same face as the next darker assigned
   # keyword, if any, or the next lighter one otherwise. If any of
   # '300', '200' or '100' remains unassigned, it is assigned to
   # the next lighter assigned keyword, if any, or the next darker
   # otherwise.

Here's an alternate table that similarly guarantees significant
bolder/lighter jumps, but also preserves round-tripping better by
taking advantage of the hole-filling rules and their biases:

   |    Inherited value   bolder  lighter
   |    100               400     100
   |    200               400     100
   |    300               500     100
   |    400               600     200
   |    500               700     300
   |    600               800     400
   |    700               900     500
   |    800               900     600
   |    900               900     700

Is there a reason why you had to clamp to 100/400/700/900 in your
table instead of doing something like this?

~fantasai

Received on Tuesday, 23 March 2010 23:24:02 UTC