W3C home > Mailing lists > Public > www-style@w3.org > September 2002

WD-css3-fonts-20020802 comments

From: Etan Wexler <ewexler@stickdog.com>
Date: 26 Sep 2002 20:00 -0700
To: www-style@w3.org
Message-ID: <comments-WD-css3-fonts-20020802@d20020926.etan.wexler>

Following are comments the CSS3 fonts working draft,

[In General]

The term "font decoration" is used too broadly.  The 'font-effect'
property and the 'font-smooth' property are not, in a normal sense,
about font decoration.  I suggest renaming section 4 as "Other font
properties" and finding new terms in the other uses of "font

1. Dependencies on other modules

"Values and Units" and "Syntax" should be under dependencies.

3.2 Font family: the 'font-family' property

"Name: 	'font-family'
Computed value:	specified value"

The computed value ought to be "[<string>,]* [<string> | none]".  Why
allow keywords other than 'none' to remain?

The symbol <family-name> should have a clear syntactical definition in
this section.  I'm envisioning:

    <string> | <identifier>+

"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."

What happens with the following?
font-family: Very\ \ \ Spacey;
Does "Very Spacey" match?  Does "Very   Spacey" match?  I say that
whitespace characters in a keyword may not be collapsed and so
"Very   Spacey" matches while "Very Spacey" does not match.

3.3 Font styling: the 'font-style', 'font-variant', 'font-weight' and
'font-stretch' properties

I would like a 'font-style' value that would toggle between 'normal' and
'italic'.  I would hesitate to suggest this feature at such a late
juncture except for my belief that the feature is easily implementable.

"Insofar as this property causes text to be transformed to uppercase"

May the 'font-variant' property affect the underlying codepoints?  From
the repeated references to glyphs, I would say not, but a statement in
the specification would be most helpful.

"Name: 'font-weight'
Computed value: specified value"

This is clearly incorrect for the relative keywords 'bolder' and
'lighter'.  I advocate that even the keywords 'normal' and 'bold'
compute to 400 and 700, respectively.

"Name: 'font-stretch'
Computed value: specified value"

This is clearly incorrect for the relative keywords 'wider' and

3.4 Font size: the 'font-size' and 'font-size-adjust' properties

"Name: 'font-size'"
"Computed value: <absolute-size> or <length>"

Why is <absolute-size> allowed as a computed value?  The
<absolute-size>, despite its name, is relative: relative to the user
agent settings.  All font sizes should compute to <length>.

"This property indicates the desired height (and width) of glyphs from
the font."

This statement could be misinterpreted to mean that the value of
'font-size' *is* the width of glyphs.

"For non-scalable fonts, the font-size is converted into absolute units
and matched against the declared font-size of the font, using the same
absolute coordinate space for both of the matched values."

This is unclear.  Does the first instance of "font-size" refer to the
computed value of the 'font-size' property?  It's just... really

"An <absolute-size> keyword refers to an entry in a table of font sizes
computed and kept by the user agent. Possible values are:
[ xx-small | x-small | small | medium | large | x-large | xx-large ]"

Should there be a requirement that each table entry be larger than the
previous table entry?

"The actual value [link to Cascading module] of this property may differ
from the computed value due a numerical value on 'font-size-adjust' and
the unavailability of certain font sizes."

I thought that 'font-size-adjust' would affect the computed value. 
After all, 'font-size-adjust' is entirely within the purview of the CSS
processor, whereas the unavailability of font sizes is the type of
external limitation which one normally associates with modified actual
values.  The compounding of 'font-size-adjust' is a problem to be
overcome, but not by meddling with the meaning of computed and actual
values.  There are implications here for every property that accepts
<length> values, especially 'line-height'.

3.5 Shorthand font property: the 'font' property

"Inherited: yes"

This should be "Inherited: see individual properties".

"The 'font' property is, except as described below, a shorthand property
for setting 'font-style', 'font-variant', 'font-weight', 'font-size',
'line-height', and 'font-family', at the same place in the style sheet."

The 'font' shorthand also sets 'font-stretch' and 'font-size-adjust',
both of which should be appended to the list of properties here.

"That is why this property is "almost" a shorthand property: 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

This is wrong.  The 'font' shorthand allows authors to achieve equal
results while knowing fewer details (not knowing, for example, what size
a system uses for caption fonts).  In no case does a 'font' declaration
set anything other than defined properties to defined values.  'Font' is
thus a thorough shorthand.

3.6 Generic font families

Add "User agents may map a generic family to a list of particular font
families, for example, in order to provide wide character coverage."

4.1 Font effect: the 'font-effect' property

I thought, pursuant to Chris Lilley's comments [1], that 'font-effect'
would be replaced by 'filter'.  What happened to that anticipated shift?

[1]  Chris Lilley.  "Re: box-shadow)ext-shadow', 'box-shadow', and
'font-effect' (was Re:   Proposal:  box-shadow)".  5 October 2001. 
<mid:3BBCECCF.47AADF47@w3.org> /

4.2 Font smoothing: the 'font-smooth' property

"Name: 'font-smooth'"
"Computed value: specified value (except for initial and inherit)"

The keyword 'auto' and <absolute-size> values should compute to

 always smooth text at any size."

This value is equivalent to a zero <length>.  I move to eliminate the
'always' value for this reason.  If 'always' is kept, though, the
equivalence should be noted.

4.3 Font emphasis: the 'font-emphasize-style' 'font-emphasize-position'
properties and the shorthand 'font-emphasize' property

I wish that these properties were named with "emphasis" in place of
"emphasize".  It feels more natural, at least to this English speaker.

"Name: 'font-emphasize'"
Inherited: yes"

It should be "Inherited: see individual properties".
Received on Thursday, 26 September 2002 22:30:11 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 27 April 2009 13:54:16 GMT