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

[L. David Baron]

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

--
L. David Baron                                 http://dbaron.org/
Mozilla Corporation                       http://www.mozilla.com/

[Andrey Mikhalev]

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
>
>

[L. David Baron]

On Wednesday 2008-06-11 17:07 +0400, Andrey Mikhalev wrote:
> 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.

So you're saying you actually know what the CSS2 definition says
should happen in these cases?  As far as I can tell it's
self-contradictory (or maybe ambiguous).

> 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?

Which 'used font-family'?  There are more than one.

-David

--
L. David Baron                                 http://dbaron.org/
Mozilla Corporation                       http://www.mozilla.com/

[fantasai]

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.

Recorded as CSS2.1 Issue 49:
   http://csswg.inkedblade.net/spec/css2.1#issue-49

~fantasai

[fantasai]

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.

The CSSWG decided not to define this in CSS2.1, and I was given an
action item to write a note that basically says that. Here's a
proposed note:

   Note: A set of nested elements that mix 'bolder' and 'lighter' will
   give unpredictable results depending on the UA, OS, and font
   availability. This behavior will more precisely defined in CSS3.

~fantasai