W3C home > Mailing lists > Public > www-style@w3.org > May 2013

[css3-fonts] Minor Comments

From: fantasai <fantasai.lists@inkedblade.net>
Date: Tue, 14 May 2013 06:24:26 -0700
Message-ID: <51923B0A.1050908@inkedblade.net>
To: "www-style@w3.org" <www-style@w3.org>
http://dev.w3.org/csswg/css-fonts/#typography-background

   # If a document contains characters not supported by the
   # character maps of the fonts contained in a font family
   # list, a user agent may use a system font fallback
   # procedure to locate an appropriate font that does.

MAY seems a little wiggly here, shouldn't it be MUST?
Or at least s/may use/uses/.

   # Fallback can occur when the list of font families
   # does not include a font that supports a given character.

  s/Fallback/System fallback/
  s/can occur/occurs/
  s/when the list/when the specified list/

   # Given the availability of the fonts below, Futura
   # would match but Futura Medium would not:

Prepend "For example, ".

http://www.w3.org/TR/2013/WD-css3-fonts-20130212/#font-weight-prop

   # The ‘font-weight’ property specifies weight of glyphs
   # in the font, their degree of blackness or stroke thickness.

s/weight/the weight/
s/,/:/

   # Specifies the weight of the face bolder than the inherited value.

This seems to be wording left over from when we calculated
against the available font weights rather than the table, suggest

   | Specifies a bolder weight than the inherited value.

Likewise for 'lighter'.

   # Font formats that use a scale other than a nine step scale

s/nine step/nine-step/

   # Although the practice is not well-loved by typographers,
   # bold faces are often synthesized by user agents for faces
   # that lack actual bold faces.

This paragraph should probably contain a cross-reference to the
'font-synthesis' property, so we know it exists and influences
this behavior.


*** The following edits correct errors in value-stage terminology. ***

   # Values of ‘bolder’ and ‘lighter’ indicate values relative
   # to the weight of the parent element. Based on the inherited
   # weight value, the weight used is calculated using the chart
   # below. Child elements inherit the calculated weight, not a
   # value of ‘bolder’ or ‘lighter’.

s/Values/Specified values/
s/indicate values/indicate weights/

s/weight used/computed weight/
Might also consider swapping around the clauses like this:
   | The computed weight is calculated based on the inherited
   | 'font-weight' value using the chart below.

s/calculated weight/computed weight/, however this last sentence
is now redundant because we used correct terminology! ^_^

Also, the Computed value line in the propdef table should probably
say "a numeric weight value" or somesuch rather than "see description".

*** ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~  ***

   # The table above is equivalent to [...]

This sentence should probably be <p class="note">.

   # Authors who desire finer control over the exact weight values
   # used for a given element should use numerical values instead
   # of relative weights.

I'm not sure this is an RFC 2119 SHOULD, in fact I'm quite sure
it is not, since it's giving advice, not stating a conformance
requirement. So ideally, this sentence should be worded to not
use "should", or at least be stuck in a note so it's clearly
non-normative.

http://www.w3.org/TR/2013/WD-css3-fonts-20130212/#font-stretch-prop

   # Absolute keyword values have the following ordering, from
   # narrowest to widest:

But then proceeds to give a list of terms that are not, in fact,
those keywords. I know it's prettier to have capitals and spaces,
but if you're saying you're giving a list of keyword values, they
should actually be those keyword values. ;)

~fantasai
Received on Tuesday, 14 May 2013 13:25:00 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 14 May 2013 13:25:01 UTC