W3C home > Mailing lists > Public > www-style@w3.org > April 2010

Re: [css3-fonts] various comments and typos

From: John Daggett <jdaggett@mozilla.com>
Date: Mon, 5 Apr 2010 01:15:23 -0700 (PDT)
To: Bert Bos <bert@w3.org>
Cc: W3C style mailing list <www-style@w3.org>, Steve Zilles <szilles@adobe.com>
Message-ID: <1711477272.99368.1270455323728.JavaMail.root@cm-mail03.mozilla.org>

Bert, thanks very much for your comments.

Bert Bos wrote:

> A mixture of editorial and other comments on
> http://dev.w3.org/csswg/css3-fonts/
> [I know it is not very useful to comment in e-mail on editors' drafts,
> if only because in a few days or weeks the above URL doesn't contain
> anymore what my comments refer to, but we didn't have time to discuss
> the comments in the WG meeting and maybe this way they still serve some
> purpose...]

As Etan Wexler pointed out to me, you can refer to individual edits using the CVS log:


Your comments refer to v.1.34 (the server inserts charset=iso-8859-1 by default, grumble):


Version containing corrections based on your comments:


> a) Section 3.7 says that 'font-stretch' is reset by the 'font'
> shorthand, but cannot be set. But it seems straightforward and
> unambiguous to allow it in the shorthand.

This might make sense but the 'font' shorthand is awfully overloaded
as it stands, I'm somewhat hesitant about this.

> b) In answer to the open issue in section 4.3: no, there is no need
> for a registry until new formats are defined at a rate of one every
> month or so... So far, WOFF is the first new format in nine years.
> We can easily keep up with that through the normal CSS
> standardization process.

I think that's a fair point but Steve Zilles requested this be listed
as an issue at the Sophia F2F last year.  Steve, do you feel this remains
an issue to be considered?

> c) Section 4.3 says the <font-face-name> can optionally be enclosed in
> quotes. Should there be a note that certain characters must be escaped
> otherwise? Should, e.g., commas be escaped to preserve some
> extensibility? Should the syntax be the same as for 'font-family'
> (defined in CSS 2.1)?

That would seem to make sense but I'm a little concerned that the
rules for font-family seem to be limited by how the 'font' shorthand
is parsed.  That imposes all sorts of strange restrictions that don't
seem to make sense in the src: local() case.

> d) In section 4.3, example IX, is the 'local(Gentium)' meant to be a
> font face name? It looks like a family name.

For regular faces the fullname of an individual font face is the same
as the family name:


Fonts *can* use something else but Gentium Regular uses the fullname
(name id 4) of 'Gentium'.  Under OSX, open FontBook and choose a
specific font face, then select Preview > Show Font Info.  Look for
the name listed as "Full name". For Windows you can use the font
properties extension (downloadable from Microsoft) and Linux has font
utilities that display similar information.

> e) Section 4.4 says that UAs may modify the font is the 'font-weight'
> descriptor is 'bold' and the data in the font itself says its not bold.
> But shouldn't the font be used unchanged? Apparently the author intended
> for this font to be used as the bold font, even though the font designer
> didn't think it could be.

Yes, this behavior was discussed during the Sophia F2F:


This allows authors to arrange a family as they prefer.  This also
protects authors from having to deal with cross-platform
inconsistencies for how font weight is determined (i.e. using the OS/2
table weight value vs. inferring it from the style name or some other

Another reason for this is that to determine which face to download,
style information in the @font-face definition is used to choose a
face to download. If you need the font weight from the font to
determine this then all the faces need to be downloaded before running
through the weight mapping algorithm.

> g) Section 6.1: Is this property needed? The UA can turn kerning off if
> it (or the user) wants, but there doesn't seem any need for the author
> to turn it of.

No, I think it's better that kerning be enabled by default and the
author (or user) have the ability to override that.  This shouldn't be
something user agents disable by default.

> i) Section 6.5: Wouldn't spelling out the names to 'lining-numerals',
> 'oldstyle-numerals', etc. make them easier to remember?

Yeah, I was trying to limit value names like 'proportional-numerals'
but I suppose using the unabbreviated form is better.

> j) Section 6.5, under "diagonal-fractions": the illustration makes it
> look as if the the three characters "1/3" turn into a ligature, but that
> is not the case. The feature chooses between two styles for the
> predefined fractions in Unicode: ¼ ½ ¾ ⅓ ⅔ ⅕ ⅖, etc.

As others have pointed out, this is incorrect, this feature enables automatic
fractions for character seqences like "7/3" and is unrelated to the Unicode
codepoints you mention.

> Editorial:
> 11) All property definitions: remove the 'inherit' keyword, it's
> implicit. (Could instead have an introductory section about how to
> read the spec, which refers to section 1.4.1 in CSS 2.1:
> http://www.w3.org/TR/CSS21/about.html#property-defs)

Hmmm, many of the font properties in the CSS 2.1 spec include
'inherit' as a property value, why is that not implicit there also?
Received on Monday, 5 April 2010 08:16:00 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:38:33 UTC