WD-CSS21-20020802 section 15, "Fonts", substantive comments

Following are substantive comments on section 15, "Fonts"
(<http://www.w3.org/TR/2002/WD-CSS21-20020802/fonts.html>), of the
Cascading Style Sheets level 2.1 draft
(<http://www.w3.org/TR/2002/WD-CSS21-20020802>).



15.2 Font matching algorithm


"Further computations, e.g. by 'em' values in other properties, are based
on the 'font-size' value that is used, not the one that is specified."

In other words, the 'em' unit corresponds to the actual 'font-size' value.
This contradicts section 4.3.2, "Lengths":

"The 'em' unit is equal to the computed value of the 'font-size' property
of the element on which it is used."



15.3 Font family: the 'font-family' property


"Unlike most other CSS properties, values are separated by a comma to
indicate that they are alternatives"

Change "values" to "names".  "Value" in CSS means everything associated
with a property name, not just one or a few terms.


"body { font-family: gill, helvetica, sans-serif }"

This example encourages misnaming font families in all lowercase.
Capitalize "gill" and "helvetica".


"<family-name>
The name of a font family of choice. In the last example, "gill" and
"helvetica" are font families."

This is quite unhelpful.  A much better definition follows

<string> | <identifier>+


"The following generic families are defined:
'serif' (e.g. Times)
'sans-serif' (e.g. Helvetica)
'cursive' (e.g. Zapf-Chancery)
'fantasy' (e.g. Western)
'monospace' (e.g. Courier)"

Eliminate the quote marks and move the examples to a passage after the
list.  As it stands, people are likely to misread the specification as
endorsing quoted generic family names.


"body { font-family: "new century schoolbook", serif }"

Again, capitalize the font name as an example of best current practice.


"If quoting is omitted, any whitespace characters before and after the font
name are ignored and any sequence of whitespace characters inside the font
name is converted to a single space. "

This should be true only when the whitespace characters are delimiters.
When escaped and included in an identifier proper, whitespace should be
neither ignored nor collapsed.



15.5 Small-caps: the 'font-variant' property


"The following example results in an 'H3' element in small-caps, with
emphasized words in oblique small-caps:

h3 { font-variant: small-caps }
em { font-style: oblique }"

There is no guarantee that an 'em' element will occur within an 'h3'
element, so the statement about emphasized words is false.



15.7 Font size: the 'font-size' property


"On all other properties, 'em' and 'ex' length values refer to the font
size of the current element. On the 'font-size' property, these length
units refer to the font size of the parent element."

When the conflict between using computed and using actual font sizes is
resolved, the particular stage of the values should be mentioned here.



15.8 Shorthand font property: the 'font' property


"The 'font' property is, except as described below, a shorthand property"

As I have written previously, 'font' is a pure shorthand without
exceptions.  Unless a 'font' declaration can produce something other than
declarations of its constituent properties, there is truly no basis for
saying that 'font' is not a shorthand.  The fact is that 'font' merely
makes easier the assignment of values to properties; 'font' does not
introduce new properties or new values.


"p { font: x-large/110% "new century schoolbook", serif }"

Capitalize "new century schoolbook".


"system fonts can only be specified with this property, not with
'font-family' itself, so 'font' allows authors to do more than the sum of
its subproperties."

Wrong.  'Font' allows authors to do more stuff with less knowledge.
However, if I knew the system-provided values to assign to the constituent
properties, I could mimic exactly each system keyword value for 'font'.

Received on Thursday, 14 November 2002 07:12:54 UTC