Re: [css3-fonts] @font-feature-values syntax

As far as B vs A, this is similar to SASS syntax vs SCSS syntax, right? Although the non-bracketed code may use less characters, the bracketed version tends to be easier to "run with". You don't have to abstract your thinking any further if you are just using the same pattern as when writing normal selectors and properties.

+1 for the bracketed version.

Joel Glovier


On Sep 25, 2012, at 11:34 PM, Glenn Adams <glenn@skynav.com> wrote:

> 
> 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.
>