Re: [css3-fonts] Nested 'bolder' and 'lighter' question

L. David Baron wrote:

> 15.6 contains some contradictory statements as a result of previous
> edits [1] which were themselves needed to resolve existing
> contradictions.  See
> http://csswg.inkedblade.net/spec/css2.1#issue-48 (and note that what
> we're discussing is issue 49).

Another way to solve issue 48 may be to re-use the concept of "first 
available font" that we introduced to define the value of 'ex'.

Concretely: remove no text from 15.6, but add this bullet point before 
the two that define 'bolder' and 'lighter'. It says to only look at the 
first family:

   * Determine the font weight mappings of all fonts (of any style, size
     or variant) in the first family in 'font-family' that has any fonts
     available. Compute the used value of 'font-weight' using this set of
     fonts, as follows:

The existing bullets could remain unchanged or cleaned up to avoid some 
confusion and ambiguities, as follows:

   * 'bolder' selects the next weight that is assigned to a font that is
     darker than the *parent's weight* [was: inherited one]. If there is
     no such weight, it simply results in the next darker numerical value
     [remove: (and the font remains unchanged)], unless the inherited
     value was '900' in which case the resulting weight is also '900'.

   * 'lighter' is similar, but works in the opposite direction: it
     selects the next lighter keyword with a different font from the
     *parent's weight* [was: inherited one], unless there is no such
     font, in which case it selects the next lighter numerical value
     [remove: (and keeps the font unchanged)].



With this addition the original algorithm (next available font or +100) 
is well-defined again and the outcome of Fantasai's puzzle is as 
Sylvaing said:

b -> 700 (because a bolder font is available and it has weight 700)
c -> 800 (because no bolder font is available, so we just add 100)
d -> 700 (because a lighter font than 800 is available, viz., 700)

and thus d is bold.

It will satisfy some people's intuition ("in an ideal font d would be 
bolder than a") and fail others ("in an ideal font, d would be lighter 
than c"). You can't win...



For issue 49, this means that the computed value of 'font-weight' is 
neither a sequence nor a count, it is simply an absolute weight 
(100..900), *but* it cannot be computed without knowing the available fonts.

That shouldn't be a problem in most cases, except when the font is not 
yet downloaded when you compute property values. In that case you must 
either wait until the font is downloaded and installed, or continue 
assuming the font does not exist and recompute properties if it later 
turns out that the font downloaded and installed fine.

The same is true for any calculations that involve 'ex', so it's nothing 
new.



Bert
-- 
   Bert Bos                                ( W 3 C ) http://www.w3.org/
   http://www.w3.org/people/bos                               W3C/ERCIM
   bert@w3.org                             2004 Rt des Lucioles / BP 93
   +33 (0)4 92 38 76 92            06902 Sophia Antipolis Cedex, France

Received on Friday, 29 August 2008 15:49:13 UTC