Re: [css3-fonts] new editor's draft posted

Hi Liam,

> In section 5,
> [[
> If a font family defined via @font-face rules contains only invalid font
> data, it should be considered as if a font was present but contained an
> empty character map; matching a platform font with the same name must
> not occur in this case.
> ]]
> seems to mean that if you have an @font-face rule for an EOT Palatino
> (say) and your browser doesn't support Palatino, the system Palatino
> font must never be used as a fallback; that seems suboptimal.

The name of @font-face families is chosen by the author and those
names take precedence.  If the author happens to name their font
family "Headline" but the load fails, then this is just saying that
the UA shouldn't match a system font that just happens to be named
"Headline".  To put it another way, by defining an @font-face family
with a given family name the author is declaring explicitly the
mapping of a family name to a given set of font faces.  Fallbacks
can easily be handled by using the fontlist itself or via the
@font-face loading mechanism.

> > * Section 6.12 font-feature-settings syntax
> > http://dev.w3.org/csswg/css3-fonts/#font-feature-settings-prop
> >
> > The syntax for access to low-level OpenType features is now more
> > CSS-like rather than a long string of tag-value pairs.
> 
> I am not convinced by making all of the hard-coded sub-properties.
> The stability of the Adobe opentype feature registry isn't clear,
> and I think having "low-level" and "high-level" access to the same
> features confusing - you can turn ligatures on with one property
> and off again with another, they are not orthogonal.  In addition,
> as new features are added from time to time, or for other font
> formats, CSS would need to be updated.

The syntax requires the use of arbitrary CSS identifiers, much like
font family names (see recent CSS 2.1 edits), there's no "hard coding"
here.

But during the CSS F2F discussion of this syntax, it was decided that
that rather than allowing unquoted tagnames, all tagnames should be quoted.
So the revised syntax is now:

 font-feature-settings: "tagname" [<integer> | on | off]? [, "tagname" [<integer> | on | off]? ]*

Simple examples would be:

 font-feature-settings: "smcp", "swsh" 2;   /* smcp=1, swsh=2 */
 font-feature-settings: "liga" off;         /* liga=0 */
 font-feature-settings: "ss03", "ss05" on;  /* ss03=1, ss05=1 */
 font-feature-settings: "TWZ6";             /* TWZ6=1 (non-standard custom feature) */

> (2) allow "inherit" and "default" (or "normal") as well as on and off

So these are per-feature?  I can see how this would work, I'm not
sure I see such a strong use case.

> (3) allow any mix of the "friendly" and "unfriendly" feature names
> in the two properties (for selection and for manipulation)

???

> (4) consider a conditional, @when (font-family: "x") { stuff here
> } or something. Although this is getting to the point where people
> would use JavaScript in environments where style manipulations are
> scriptable.

For setting defaults, these can be set within @font-face rules.  See
section 4.6.  This allows a designer to choose a particular font with
a specific set of alternates as the default.

Received on Thursday, 10 March 2011 16:47:53 UTC