Re: bolder/lighter defintion

On 03/23/2010 11:56 PM, John Daggett wrote:
>
> fantasai wrote:
>
>> On 03/23/2010 08:24 PM, L. David Baron wrote:
>>> On Tuesday 2010-03-23 16:23 -0700, fantasai wrote:
>>>> 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
>>>
>>> Is there a use case for that?  Is lighter inside bolder something we
>>> expect to be common?  In what cases?  Do they rely on this invariant?
>>
>> I don't have any expectations of whether it would be common or
>> uncommon, but I find it disturbing that round-tripping would not work
>> for so many starting values and that in a font with 9 weights as soon
>> as you start using 'bolder' or 'lighter' you drop out half the
>> possible weights. If there's no good reason to break this, I don't
>> think we should.
>
> I don't see the importance of round tripping in this case, it's the
> clear visual distinction between weights that's important with
> bolder/lighter. Authors expect bolder to mean a distinct change in
> weight and subtle weight changes don't give that, shifting from
> regular to medium for example.
>
> For a concrete example, consider the Helvetica Neue family provided
> with Mac OS X.  The page below explains how an additional weight
> affects page rendering:
>
> http://emps.l-c-n.com/notebook/HelveticaNeue-font-weight
>
>    "With the release of OS X 10.6, Apple provides one additional
>     face: ‘Medium’, with font-weight: 500. For a web developer
>     (and more so for the end–user of a web page…), this results
>     in a small surprise. When viewing a page that contains
>     <strong>  or<b>  elements with a Gecko based browser, those
>     elements suddenly look much less dark or fat than they used
>     to on OS X 10.5. This is not unexpected, as the Gecko UA
>     stylesheet (html.css) specifies b, strong {font-weight:
>     bolder;}. The browser looks for a face that is one weight
>     heavier than the previous one and finds the Medium face of
>     Helvetica Neue."
>
>> The table I came up with has equivalent behavior to John's for a
>> 100,400,700,900 font. Assuming you're mapping to the font tables
>> after calculating the computed value (which is what I thought we'd
>> agreed on), I don't see why we need to lose precision here for fonts
>> with a greater range of weights.
>
> Relative weights are used for visual distinction.  Authors can use
> specific weights for more precise control.

Yes, you've brought up this point about the current algorithm not
providing adequate visual distinction several times at various F2Fs.
IIRC, you mentioned that at least two steps were needed to cause a
distinct jump in font weight.

Anyway, you're criticizing my table for providing inadequate visual
distinction, but haven't provided an example where that's the case.
Can you please provide such an example?

> It's unfortunate that you're bringing this up now, a year after this

It's unfortunate that I'm only now triaging the CSS2.1 issues list, yes.

> was discussed and agreed upon at the March 2009 F2F.

There was no resolution on font-weight at that F2F:
   http://lists.w3.org/Archives/Public/www-style/2009Mar/0070.html

> During the discussion then you were chatting online and giggling,
> I remember thinking "I'm not that funny". :P

That comment was uncalled-for.

~fantasai

Received on Wednesday, 24 March 2010 08:16:42 UTC