Re: [css3-fonts] font-feature-settings syntax

Jonathan Kew wrote:

> > I propose changing the wording above to:
> >
> >    The<string>  is a case-sensitive OpenType feature tag. For it
> >    to match an OpenType feature contained in a font, it must
> >    follow the syntax rules for these tags. As specified in the
> >    OpenType specification, feature tags contain four ASCII
> >    characters. Tag strings longer or shorter than four characters,
> >    or containing characters outside the U+20-7E codepoint range
> >    must be treated as invalid.  User agents must not use a feature
> >    tag created by truncating or padding the string to four
> >    characters.
> 
> Whether this is a good thing to do depends, it seems to me, on
> whether we want font-feature-settings to be explicitly targeted at
> the OpenType model, or to be a more general property that could, at
> least in principle, be used to control other font-rendering backends
> that might take a different approach to identifying features that
> the user may want to control.

I've brought this up in previous discussions and each time the clear
consensus is that we need to focus on OpenType support for this level.
This doesn't close the door to other font technologies, it simply
acknowledges that OpenType is the defacto standard among implementors
and type designers.

This property is a way of exposing less commonly used or custom
low-level features; commonly supported features are intended to be
supported via the other font-variant subproperties.  Those
subproperties are more font technology agnostic (although based on
features supported in OpenType).

I should emphasize again that making the syntax specific to the syntax
used by OpenType is *not* equivalent to restricting the syntax to
OpenType in the future.  By tightening the syntax now we assure that
future property values used to support not-yet-invented font technologies
will be treated as invalid by current user agents.

> For example, in the AAT font model, features are not identified by
> 4-character tags; they use pairs of integer values (feature,
> selector), but also provide human-readable names for features; users
> would not be expected to have any awareness of the exact numeric
> values involved, and font designers are not constrained by any
> registry of possible features. In a hypothetical (but hardly
> far-fetched) UA that provided support for user control of AAT
> features, I'd expect to be able to say something along the lines of
> 
>      font-family: "Hoefler Text";
>      font-feature-settings: "Style options=Engraved Text";

As brilliant as many of the aspects of AAT were originally,
unfortunately I think it is far-fetched that AAT will be widely
supported as a web standard font technology and by the type design
community.  And *if* it was considered important in the future, I
think there are many ways the syntax of font-feature-settings could be
expanded to support something like this.

Example:

  font-feature-settings: aat("Style options=Engraved Text");

There are all sorts of issues, how to prioritize different font
formats, whether multiple formats are supported, etc.  But this
*isn't* a problem that needs to be tackled as part of the CSS3 Fonts
spec.

> If we expect that font-feature-settings might some day be used for
> systems other than OpenType, then, perhaps we shouldn't try to enforce
> the specific form of OpenType tags at the CSS syntax level, but rather
> say that syntactically, any <string> is valid. A <string> that does not
> conform to the requirements of an OpenType feature tag will of course be
> ignored by the font-rendering backend, just as a valid OpenType tag that
> doesn't happen to be supported in the current font will be ignored; but
> it would not be a CSS error that leads to the entire rule being discarded.

This is equivalent to saying that user agents should accept as "valid"
values that are not supported by that user agent.  There's no
future-proofing in this model, no way for authors to write different
rules for different user agents, it's not the right way to handle
unsupported values in CSS.  For an example of unsupported value
handling, see the 'kashida' property value of text-justify [1].

Regards,

John Daggett

[1] CSS3 Text text-justify 'kashida' value
http://dev.w3.org/csswg/css3-text/#kashida-prop

Received on Monday, 23 April 2012 00:45:26 UTC