[css3-fonts] Behdad's Feedback on CSS Fonts Module Level 3 Editor's Draft 5 April 2010

Hi all,

I recently got to review the CSS Fonts Module draft at:


What follows is my quick feedback from one reading of the spec.


3.1.1 Generic font families

To reduce confusion I suggest adding Arabic specimen to the serif, sans-serif,
and monospace generic samples.  For monospace, DejaVu Sans Mono can be used.
For serif I suggest Nazli (from FarsiWeb), and for sans-serif, either Roya
(from FarsiWeb; more of a serif / sans-serif hybrid) or Iranian Sans.  I can
provide samples.

Under monospace, it may be worth talking about CJK.  Most CJK monospace fonts
have ideographs that take twice the space of non-ideograph glyphs, and I think
those are acceptable "monospace" fonts.

3.3 Font width: the font-stretch property

Add a hint that agents may synthesize stretch?

3.6 Relative sizing: the font-size-adjust property

I think this is a big hack.  To begin with, there's no x-height for most
non-Western scripts.  How is that supposed to work?

On a related note, would be useful to allow scaling fonts defined in
@font-face rules.  A syntax like:

@font-face {
  font-family: Gentium;
  src: url(http://site/fonts/Gentium.ttf) at 110%;

for example.  When mixing Arabic and Latin fonts, such adjustments are
typically desired.

4.3 Font reference: the src descriptor

This part of the text:

 Conformant user agents must skip downloading a font resource if the
 format hints indicate only unsupported or unknown font formats.

I suggest using "may".  If the font is not skipped, it's downloaded, garbage
found, and skipped.  So there is no need for the "must".

Moreover, the property mixes two different notions: the font container, and
the smart font technology.  For example, what would one put in there for a AAT
font in WOFF wrapper?

Issue: the src as it is designed right now, makes it impossible to use
TrueType Collection fonts.

Issue: should @font-face rules be able to reference other @font-face's?

5 Font matching algorithm

This sentence:

 If two faces have the exact same style characteristics, one of
 them is ignored.

should be removed IMO.  If two fonts have the same style properties but
different coverages, they are both useful.  Indeed, Linux platforms do such

This part:

 2. If the family name is a generic family name, the user agent looks
 up the appropriate font family name to be used. User agents may
 choose the generic font family to use based on the language of the
 containing element or the Unicode range of the character.

Why allow a per-Unicode-range selection but not per-character?  For example,
what would happen of the per-language or per-Unicode-range family doesn't
support the character at hand?  Currently, my reading suggests that the
generic matching fails and we move to the next family.  Whereas I think the
right thing to do would be to find a generic font that supports the character.

6.9 Low-level font settings control: the font-feature-settings property

The main issue I see with this is that setting a feature breaks inheritance
and essentially unsets any features set higher in the document hierarchy.
Say, I can't enable a feature on <body> and have it affect the entire document
if I also want to control a totally unrelated feature on some elements.  To
resolve that, the "Computed value" needs to change to accumulate the specific
feature setting to what's inherited.  A value setting of normal (possible
followed by more settings) can be used to break the inheritance.  Most
probably I don't understand how CSS inheritance really works.  Otherwise, I
don't see why an 'inherit' value is not among the possible values for

The text mentions:
 For OpenType features that are boolean in nature, a value of 0
 disables the feature and a non-zero value enables the feature.

I suggest using 1 for enabling boolean features and an undefined behavior if
other values are used.

Moreover, would be nice to have a way to specify that a specific setting is an
OpenType feature tag, and have an extension mechanism for future additions of
AAT and possibly other systems.  Alternatively, the current method can be
used, and any engine just pickup whatever provided features that apply to the
underlying font format.

6.10 Font language override: the font-language-override property

In this sentence:

 The value of ‘normal’ implies that when rendering with OpenType fonts
 the language of the document is used to infer the OpenType language

Is "document language" really what should be used, or the XML language of the
element at hand?

Another way to address the issue this tag tried to address would be to
register a BCP 47 Extension subtag for OpenType LangSys.

Received on Thursday, 12 August 2010 14:12:35 UTC