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

Re: [css3 fonts] font-specific features

From: John Daggett <jdaggett@mozilla.com>
Date: Mon, 27 Sep 2010 22:00:46 -0700 (PDT)
To: John Hudson <tiro@tiro.com>
Cc: www-style <www-style@w3.org>, www-font <www-font@w3.org>
Message-ID: <439319241.56617.1285650046426.JavaMail.root@cm-mail03.mozilla.org>
John Hudson wrote:

> Fallback to the first variant -- as happens for e.g. the <salt>
> feature in current applications that do not provide access to
> enumerated variants -- is not acceptable in such a situation, since
> it would result in an inaccurate transcription of the object being
> catalogued.

So you're saying setting salt = NNN implies salt = 1 when no lookup exists
for NNN?  In other words, the two style rules below would be the same, assuming
no font supports a lookup value of NNN:

  @font-feature-settings MyFont {
    stylistic: wacky 666;
  }

  p { font-family: MyFont; }
  p#test1 { font-variant: stylistic(wacky); }
  p#test2 { font-feature-settings: salt(1); }

Things like this need to be captured somewhere in a spec.  If OpenType
doesn't define default behavior explicitly in these cases, it needs to
be defined explicitly somewhere.  I think in general the rule should
be that if a given feature is specified and a given font doesn't
support it, the glyph used should be the same one used if the feature
was not specified explicitly (i.e. whatever the OpenType engine
defaults would be).  Having undefined per-feature defaults defined at
an engine level is a recipe for incompatibility across user agents.

John Daggett
Received on Tuesday, 28 September 2010 05:01:21 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:31 GMT