[css21] Make font weight mapping rules normative

>From the F2F discussion of CSS 2.1 issues:

CSS 2.1 Issue 156
http://krijnhoetmer.nl/irc-logs/css/20100329#l-159
Original posting: http://lists.w3.org/Archives/Public/www-style/2009May/0198.html

> plinss: Related is issue 156.
> fantasai: ChrisL says "I'd prefer to see the mapping made normative."
> fantasai: Different mapping from issue 111.
> # # [19:08] <fantasai> http://www.w3.org/TR/CSS21/fonts.html#font-boldness
> # # [19:08] <fantasai> last bullet in the list
> # # [19:08] <fantasai> "If there are fewer then 9 weights in the family"
> ChrisL: above that, it says "in typical cases", which makes it untestable.
> ChrisL: So, I'd like to drop that sentence.
> fantasai: OpenType fonts use a numerical scale, but they may not line up with multiples of 100.
> ChrisL: 4th bullet gives you a more precise description of that.
> ChrisL: I've seen things like a font with weights like 400 and 250, and that's fine. 200 and 300 aren't mapped explicitly.
> fantasai: You might actually want to map the 250 to 100.
> ChrisL: No, that'd expose more weights, but would put them in the wrong place. If you need precise mapping, just use @font-face.
> plinss: I think certain platforms made fonts map their weights wrong to get around bad heuristics.
> ChrisL: I haven't seen platform-specific weight tables like that.
> fantasai: I'm happy to make bullet 4 normative, but I'm less convinced about the other rules being normative.
> fantasai: I think mapping fonts to weights can be messy, and we shouldn't define that in css 2.1
> fantasai: But after the font has been mapped into the CSS font-weight scale, then we can follow the guidelines in bullet 4 to find missing weights.
> fantasai: That seems consistent.
> fantasai: The rules before that are about establishing the scale, and needs to be flexible to accomodate whatever twisted things we get into with fonts.
> # # [19:15] * dbaron wonders if jdaggett should be around for this discussion
> fantasai: So the specific changes for this would be to pull bullet 4 out of the list and remove "typical".
> # # [19:15] <fantasai> remove "default"
> s/typical/default/
> # # [19:16] <fantasai> Chris: Replace "typical mappings" from the sentence below to "this mapping"
> RESOLVED: Pull bullet 4 of the font-weight mapping rules out into its own paragraph, tweak wording to imply exactness, not "typical" or "default".

There may have been other things said here that weren't captured in
the IRC log but I'd like to point out that there are two basic issues
with font weights:

(1) Given a specific value of font-weight, which face within a set
    of faces for a given family should be selected?

(2) Given a set of font faces, how to assign them onto the CSS 100 .. 900 scale?

The current wording in the CSS 2.1 spec doesn't completely address
(1), the mapping of weights 400 and 500 is not completely clear in the
current wording. I've tried to clear this up in the CSS3 Fonts spec. 

Specifically, if a 400 weight is not available what's the mapping? 
The logical choice I think is to use a 500 weight if available,
otherwise a lighter weight.  If 500 is specified and no 500 weight is
available, the next lighter weight is used.  The current spec only
infers that a 400 weight is chosen, this leaves ambiguous situations
like the Hiragino Kaku Gothic Pro family under OSX which has weights
300 and 600.

As for the point (2), I share the desire to have a normative mapping
but this is really very hard to define normatively because of the long
history of limitations and hacks that surround this issue.
OpenType/TrueType fonts typically contain data that indicates an
integer weight value between 100 and 900.  Usually this is a multiple
of 100 but not always. For some fonts these values have been skewed to
work around API limitations.  In some situations style names override the
weight value in strange and wonderful ways.  See the details here:

  http://lists.w3.org/Archives/Public/www-style/2010Mar/0368.html

I'm not sure the wording in the current 2.1 spec really qualifies as a
defined way of resolving (2), Chris L seems to be suggesting that it
is or could be.

Regards,

John Daggett
Mozilla Japan

Received on Tuesday, 30 March 2010 07:19:52 UTC