W3C home > Mailing lists > Public > www-style@w3.org > March 2010

Re: bolder/lighter defintion

From: Thomas Phinney <tphinney@cal.berkeley.edu>
Date: Tue, 23 Mar 2010 19:12:06 -0700
Message-ID: <f49ae6ac1003231912o7e1174c8m73f678a1e2f49924@mail.gmail.com>
To: fantasai <fantasai.lists@inkedblade.net>
Cc: John Daggett <jdaggett@mozilla.com>, www-style <www-style@w3.org>
On Tue, Mar 23, 2010 at 4:23 PM, fantasai <fantasai.lists@inkedblade.net> wrote:
> 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

I think I mentioned before, one limitation of this table is that it
only handles values in even 100s, when real-world fonts sometimes use
in-between numbers. Notably (but not only) some fonts from Adobe.

Cheers,

T

-- 
"The rat's perturbed; it must sense nanobots! Code grey! We have a
Helvetica scenario!"  http://xkcd.com/683/
Received on Wednesday, 24 March 2010 02:12:41 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:25 GMT