Re: [CSS21] computed value of 'font-weight' is not precisely defined

imo both cases do not achieve desired effect, i.e. prevent weight 
inversion on font-family swing.
if you won't bother with it, just return back to pretty simple CSS2
definition.
and i think w/o 'used font-family' thing on computation stage you cannot 
solve the problem; then no reason to keep neither sequence nor count of 
relative values.
so, why particular [weird?] impl must be freezed in spec?

On Tue, 10 Jun 2008, L. David Baron wrote:

>
> CSS 2.1 added the following text:
>  # The computed value of "font-weight" is either:
>  #
>  #    * one of the legal number values, or
>  #    * one of the legal number values combined with one or more of
>  #      the relative values (bolder or lighter). This type of
>  #      computed values is necessary to use when the font in
>  #      question does not have all weight variations that are
>  #      needed.
> http://www.w3.org/TR/2007/CR-CSS21-20070719/fonts.html#font-boldness
>
> This text doesn't say what specified values lead to these computed
> values.  It is, in fact, ambiguous, and could lead to two different
> sets of results, as explained below.
>
> I believe it should either:
>
> (1) make the following points normatively:
>
> * the computed value is a legal number value combined with an
>   <em>ordered sequence</em> of relative values.
>
> * when the specified value is a value other than 'bolder' or
>   'lighter', the computed value is the same as the specified value
>   (perhaps normalized)
>
> * when the specified value is 'bolder' or 'lighter', the computed
>   value is the inherited value with the 'bolder' or 'lighter'
>   appended to the ordered sequence of relative values.
>
> or
>
> (2) make the following points normatively:
>
> * the computed value is a legal number value combined with a count
>   of relative values (with positive vs. negative distinguishing
>   bolder and lighter)
>
> * when the specified value is a value other than 'bolder' or
>   'lighter', the computed value is the same as the specified value
>   (perhaps normalized)
>
> * when the specified value is 'bolder' or 'lighter', the computed
>   value is the inherited value with the count incremented or
>   decremented based on whether the value was 'bolder' or 'lighter'
>
> I think option (2) may agree more with the text I proposed removing
> in http://lists.w3.org/Archives/Public/www-style/2008Jun/0147.html .
>
>
> Then, it should give the following example (using real text, the
> license plate prefix expected on legitimate taxis in Beijing):
>
>  # The following example demonstrates why the relative values must
>  # be stored in an ordered sequence (and why opposite pairs cannot
>  # be collapsed).  Consider the following markup:
>  #
>  #   <div style="font-weight: 700">
>  #     <em style="font-weight: bolder">
>  #       <span style="font-weight: lighter">
>  #         ЪЪB
>  #       </span>
>  #     </em>
>  #   </div>
>  #
>  # Suppose that one of the characters in the text is available only
>  # in a font-family that has weights 400, 700, and 900.  In this family,
>  # starting from weight 700, bolder yields weight 900, and lighter
>  # yields weight 700, causing the chacter to be displayed using the
>  # face with weight 700.
>  #
>  # Now, suppose that the other character in the text is available
>  # only in a font-family that has weights 400 and 700.  In this
>  # family, starting from weight 700, bolder has no place to go
>
>  ... and finish by explaining how the choice of (1) or (2) above
>  affects the result (whether the character ends up weight 700
>  (option 2) or weight 400 (option 1).
>
> -David
>
>