- From: Thomas Phinney <tphinney@cal.berkeley.edu>
- Date: Tue, 23 Mar 2010 19:12:06 -0700
- 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 UTC