- 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