- From: John Daggett <jdaggett@mozilla.com>
- Date: Wed, 15 Feb 2012 22:16:54 -0800 (PST)
- To: Christoph Päper <christoph.paeper@crissov.de>
- Cc: www-style list <www-style@w3.org>
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