Re: [css3-fonts] opentype font feature support

Sergey Malkin wrote:

> UA implementation should track and inherit each feature
> independently, because value is not shorthand and can't be broken
> into individual properties. Normal inheritance does not work, and to
> understand if OpenType 'liga' feature should be applied to
> particular piece of text, three ligature types should be treated
> internally like individual properties.

As I noted last year [1], the current proposal is a compromise between
giving authors fine-grained control over typographic features and not
adding a huge number of properties.  If you consider the number of
features in OpenType that implies a *long* list of new CSS properties.
You're making the argument that CSS properties should always be
orthogonal to each other and never be compound properties.

For ligatures this would look something like this I imagine:

  font-variant-ligatures-common: none | normal | always
  font-variant-ligatures-additional: none | normal | always
  font-variant-ligatures-historical: none | normal | always

This is similar to the WPF model [2] which has orthogonal boolean
properties:

  StandardLigatures
  ContextualLigatures
  DiscretionaryLigatures
  HistoricalLigatures

This definitely gives finer control and is simpler for use via the
object model but at the cost of a lot more properties, especially if
you include all the various properties for alternates.

> - It would cause problems with cascading. Since only one of property
> declarations will be applied, following style sheet will not enable
> standard ligatures on title div: div { font-variant-ligatures:
> common-ligatures; } .title { font-variant-ligatures:
> additional-ligatures; }

I know what you're saying but this example isn't quite correct, since
common ligatures are enabled by default in OpenType.  If a specific
feature is not explicitly enabled or disabled via a property setting,
the default for the font is used (see the first paragraph in section
6).  The point you're getting at is something more like:

  div { font-variant-ligatures: no-common-ligatures; }
  .title { font-variant-ligatures: additional-ligatures; }
  
In this case titles would *not* have common ligatures disabled, so
authors would need to explicitly specify a complete set of values:

  div { font-variant-ligatures: no-common-ligatures; }
  .title { font-variant-ligatures: no-common-ligatures additional-ligatures; }

I think the question boils down to whether or not it's crucial for
authors to be able to vary the use of one type of ligature independent
of a different type of ligature.  I'm not sure I see that as being as
natural as separating properties like 'font-family' and 'font-size'.

The third alternative is something along the lines Christoph proposed,
a hierarchical system of some sort, where "higher level" ligatures
implied the enabling of "lower level" ligatures:

  font-variant-ligatures: none | common | additional | historical

In this definition, 'common' would imply 'liga' and 'additional' would
imply both 'liga' and 'dlig'.  As Thomas Phinney pointed out, there
are cases where 'historical' should not imply 'additional' and vice
versa.

Regards,

John

Original font feature proposal in June 2009:
[1] http://lists.w3.org/Archives/Public/www-style/2009Jun/0506.html

WPF font feature support:
[2] http://msdn.microsoft.com/en-us/library/ms745109.aspx

Received on Wednesday, 10 March 2010 09:53:32 UTC