- From: Glenn Adams <glenn@skynav.com>
- Date: Wed, 26 Sep 2012 11:34:32 +0800
- To: fantasai <fantasai.lists@inkedblade.net>
- Cc: "www-style@w3.org" <www-style@w3.org>
- Message-ID: <CACQ=j+f3Kt_1TzxPFscddFU0PyOFz5K4JJtUSwV1DaGX0NtnsQ@mail.gmail.com>
On Wed, Sep 26, 2012 at 5:50 AM, fantasai <fantasai.lists@inkedblade.net>wrote: > During discussions about the @font-feature-values rule syntax, there > were several variations that came up. I wanted to bring up one of the > other variations for comparison and hear what other people think about > their relative merits. > > The @font-feature-values rule is used to bind a name to a font feature > code in the context of a particular font. If multiple name bindings for > the same feature type are declared, they all take effect, except when > reusing the same name the last declared value wins. > > Variation A is the one in the draft. It looks like this: > > @font-feature-values <font-name> { > @<feature-type> <ident> <value>, <ident> <value, ...; > ... > } > > Here's an example from the draft: > @font-feature-values Mars Serif { > @styleset alt-g 1, > curly-quotes 3, > code 4 5; > @styleset dumb 25; > @swash swishy 3 5; > } > > Variation B uses a syntax similar to standard rule sets: > > @font-feature-values <font-name> { > <feature-type> { > <ident>: <value>; > <ident>: <value>; > ... > } > ... > } > > Here's the equivalent example in this syntax: > > @font-feature-values Mars Serif { > styleset { alt-g: 1; > curly-quotes: 3; > code: 4 5; } > styleset { dumb: 25; } > swash { swishy: 3 5; } > } > > The primary benefit of Variation A is that it's slightly more compact, > since it doesn't use curly braces. > > The primary benefit of Variation B is that the cascading behavior of > the name bindings behaves exactly as you would expect from the syntax: > exactly as if the feature type were an element type selector, and the > name declarations were property declarations. I vote for variation B. Variation A looks odd to me and is more likely to confuse authors IMO. Variation B is closer to the current syntax of other @rules, except that what looks like selectors in B select a feature type, but that's OK.
Received on Wednesday, 26 September 2012 03:35:22 UTC