Re: [css3-fonts] Grammar for font-variant shorthand

Christoph Päper wrote:

> >> normal | inherit | [ <common-lig-values> ||
> >> <discretionary-lig-values> || <historical-lig-values> ||
> >> <contextual-alt-values> || stylistic(<feature-value-name>) ||
> >> historical-forms || styleset(<feature-value-name> [,
> >> <feature-value-name>]*) || character-variant(<feature-value-name>
> >> [,<feature-value-name>]*) || swash(<feature-value-name>) ||
> >> ornaments(<feature-value-name>) || annotation(<feature-value-name>)
> >> || <caps-value> || <numeric-figure-values> ||
> >> <numeric-spacing-values> || <numeric-fraction-values> || ordinal ||
> >> slashed-zero || <east-asian-variant-values> ||
> >> <east-asian-width-values> || ruby ]
> >
> > The trickiness with this is the fact that *some* of the values of
> > various font-variant-xxx subproperties are mutually exclusive and
> > some are not.
> 
> It’s not like solutions to that problem – which, in my opinion,
> results from modeling the properties closely to OT features – hadn’t
> been proposed in the past. Here are two that I suggested:
> 
> Make the ligation sub-property ‘font-variant-ligatures’ take keywords
> for the most common cases instead of fine-grained font feature
> control, which remained available through ‘font-feature-settings’.
> Similar considerations apply to other ‘font-variant-*’ properties.
> <http://lists.w3.org/Archives/Public/www-style/2010Mar/0049.html>

I think I agree with you for the ligatures subproperty but not for the
other ones.  There are simply a lot of fine-grained features in OpenType
and one of the early decisions the group made was that we would group
sets of features that cover similar functionality, numeric features for
example, to avoid an explosion of new CSS properties.

As for the syntax, the complexity of the shorthand syntax has to do with
the nature of the || operator as defined for CSS syntax definitions,
it's not distributive so productions using it have to be copied into the
shorthand.

  a = [ a1 || a2 || a3 ]
  b = [ b1 || b2 || b3 ]
  
Given these definitions [ a || b ] is *not* equivalent to [ a1 || a2 ||
a3 || b1 || b2 || b3 ] because the latter allows 'a1 b2 a2' but the
former doesn't.

> Find keywords for the (now) shorthand property ‘font-variant’, e.g.
> ‘titling’ and ‘historic’, that are independent of the longhands, but
> still set them accordingly and thereby cover most frequent scenarios.
> Shorthand properties don’t have to employ every detail of their
> longhand properties. Solving common use-cases the easy way is more
> important than direct high-level access to each and every
> insignificant feature.

Sure we could limit the set of property values covered by the shorthand
but I think you would end up with authors confused as to why some values
are in the shorthand and others aren't.  Any subproperty value being permitted
in the shorthand is much easier to understand for authors.

Regards,

John Daggett

Received on Thursday, 16 February 2012 06:17:22 UTC