W3C home > Mailing lists > Public > www-style@w3.org > October 2012

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

From: L. David Baron <dbaron@dbaron.org>
Date: Wed, 10 Oct 2012 16:17:10 -0700
To: fantasai <fantasai.lists@inkedblade.net>
Cc: "www-style@w3.org" <www-style@w3.org>
Message-ID: <20121010231710.GA19085@crum.dbaron.org>
On Tuesday 2012-09-25 14:50 -0700, fantasai 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; }
>   }

I'd at least keep the @-sign in @styleset, @swash, etc.  These are
CSS-defined keywords and they're setting up definitions of things
used elsewhere, which is something we tend to use @-rules for.

> 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 worry it might look a little *too* much like property
declarations, though.  We haven't put user-defined names in the
property position before other than with var-*, which is clearly
marked as user-defined.

So far I haven't see anything to give me a strong opinion on either
side between variations A and B.

-David

-- 
𝄞   L. David Baron                         http://dbaron.org/   𝄂
𝄢   Mozilla                           http://www.mozilla.org/   𝄂
Received on Thursday, 11 October 2012 01:49:46 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:21:01 GMT