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

On Fri, Aug 29, 2008 at 10:48 AM, Bert Bos <bert@w3.org> wrote:

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


That should probably work well.  It's essentially identical to what many
people have expressed re: 'imaginary' weights that are matches by the best
of the font's ability.

Is there a particular reason you're clamping the font-weight at 900?  I
think this is probably well out of range of normal use, but if an author
*did* somehow bump into it, it'll cause the same problems that a lot of
people in this thread say they want to avoid.

~TJ