Re: bolder/lighter defintion

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.

It's unfortunate that you're bringing this up now, a year after this
was discussed and agreed upon at the March 2009 F2F.  During the
discussion then you were chatting online and giggling, I remember
thinking "I'm not that funny". :P

Received on Wednesday, 24 March 2010 06:57:24 UTC