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

Re: [css3-fonts] various comments and typos

From: Chris Lilley <chris@w3.org>
Date: Wed, 21 Apr 2010 18:28:38 +0200
Message-ID: <567338327.20100421182838@w3.org>
To: Bert Bos <bert@w3.org>
CC: W3C style mailing list <www-style@w3.org>
On Wednesday, March 31, 2010, 8:11:58 PM, Bert wrote:

BB> A mixture of editorial and other comments on
BB> http://dev.w3.org/csswg/css3-fonts/

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

I recall that when we originally added the font-stretch property, it was not added to the shorthand precisely because it was not possible to unambiguously add it. Hence the decision that the shorthand *resets* all font properties, but ones added after CSS1 can't be *set* with the shorthand.

Has that changed?

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

I tend to agree.

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

Suspect it would be better to have the same definition.

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

It does.

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

I can see that authors would want to disable kerning somethimes, so this has value.

BB> h) Section 6.4: Titling caps may look wrong in a caps-and-lowercase
BB> word, maybe there should be a note that this feature is typically used
BB> together with 'text-transform: uppercase'.

I agree.

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

But also longer. I think the current names are fine.

BB> j) Section 6.5, under "diagonal-fractions": the illustration makes it
BB> look as if the the three characters "1/3" turn into a ligature,

Not a ligature, necessarily, but it does lay out a series of figures separated by a slash as a fraction (and that should be stated explicitly in the description)

BB>  but that is not the case. 

It is the case.

"The frac table maps sets of figures separated by slash or fraction characters to corresponding fraction glyphs in the font. These may be precomposed fractions (GSUB lookup type 4) or arbitrary fractions (GSUB lookup type 1)."

for an example of use, including arbitrary fractions, see
which has such things as


BB> The feature chooses between two styles for the
BB> predefined fractions in Unicode: ¼ ½ ¾ ⅓ ⅔ ⅕ ⅖, etc.

No, it doesn't.

BB> k) Appendix A doesn't seem to belong in this spec. The "same-origin"
BB> restriction is also incompatible with W3C's Recommended Web architecture
BB> (see, e.g., section 2.5 in "Architecture of the World Wide Web, Volume
BB> One" at http://www.w3.org/TR/2004/REC-webarch-20041215/#uri-opacity)

I disagree. It needs to be specified. Although not necessarily in this specification.

 Chris Lilley                    mailto:chris@w3.org
 Technical Director, Interaction Domain
 W3C Graphics Activity Lead
 Co-Chair, W3C Hypertext CG
Received on Wednesday, 21 April 2010 16:28:46 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:07:45 UTC