W3C home > Mailing lists > Public > www-font@w3.org > April to June 2010

Re: [css3-fonts] low-level font features

From: Bram Pitoyo <brampitoyo@gmail.com>
Date: Mon, 21 Jun 2010 22:46:42 -0700
Message-ID: <AANLkTikJVtAdW9e5LLrVzjQk99vw0YwjPYfblRwqk0V5@mail.gmail.com>
To: John Daggett <jdaggett@mozilla.com>
Cc: www-font <www-font@w3.org>
> […] proposed revised syntax:
> font-feature-settings: cpsp, pkna(0);

The proposed syntax would make the CSS behavior more consistent with
the existing font-variant property draft. Do you know if
dash-separated "friendly name" would be allowed here?

So our proposed example could be typed longhand as:
font-feature-settings: capital-spacing, proportional-kana(0)

Bram Pitoyo

On Mon, Jun 21, 2010 at 7:48 PM, John Daggett <jdaggett@mozilla.com> wrote:
> I originally posted this to www-style since it's related to CSS syntax but
> I thought I would repost this here to increase the feedback.
> After some discussion with others, I'm thinking about changing the
> syntax of the 'font-feature-settings' property.  The current CSS3 Fonts
> Editor's Draft includes the ability to directly specify low-level font
> features using this property.
>  http://dev.w3.org/csswg/css3-fonts/#font-feature-settings-prop
> The property syntax is currently defined as:
>  font-feature-settings:  normal | <string>
> where <string> for OpenType fonts is a comma-separated list of
> <feature-name>=<number> paired values. Feature names for OpenType are
> listed here:
>  http://www.microsoft.com/typography/otspec/featurelist.htm
> Other font-variant-xxx properties already provide access to many
> commonly used features. This property allows access to less commonly
> used features that don't fully justify a separate property.
> Defining the syntax as a string potentially allows other new font formats
> to be supported in the future.  But it is slightly odd to be defining it as
> a string but then specifying a syntax for OpenType fonts only.
> To simplify this a bit, I'm thinking of revising this to:
>  font-feature-settings:  <featuretaglist> | <string>
>  <featuretaglist> = ident[( <integer> )]? [, ident[( <integer> )]?]*
> For OpenType fonts, <featuretaglist> must be used while for other font
> formats either <featuretaglist> or <string> can be used, without no
> defined format for non-OpenType fonts.  The <integer> value must be 0 or
> greater; if omitted the value of 1 is assumed.  Feature tags that don't
> exist are simply ignored.
> An example using the current syntax:
>  /* Turn capital spacing on, turn proportional kana off */
>  font-feature-settings: "cpsp=1, pkna=0";
> Using the proposed revised syntax:
>  font-feature-settings: cpsp, pkna(0);
> For OpenType fonts, the example below would be valid syntax but would be
> effectively ignored since neither of the tags are valid OpenType feature
> tags:
>  font-feature-settings: this(5), that(0);
> This syntax feels more CSS-like and eliminates the use of quoted strings
> for OpenType fonts.  I don't know if it can completely express feature
> settings for other font formats.  The ability to specify a <string>
> allows some room for defining a way of specifying feature settings for
> future font formats.
> It would be very helpful to hear whether better support for AAT font
> features should also be defined here (especially folks from Apple) or
> if there are other font formats that should also be considered.
> Regards,
> John Daggett
Received on Tuesday, 22 June 2010 13:00:57 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:37:34 UTC