W3C home > Mailing lists > Public > www-style@w3.org > November 2010

Re: @font-feature-values rule syntax

From: John Daggett <jdaggett@mozilla.com>
Date: Mon, 15 Nov 2010 04:14:06 -0800 (PST)
To: Anne van Kesteren <annevk@opera.com>
Cc: www-style@w3.org
Message-ID: <182440885.348475.1289823246891.JavaMail.root@cm-mail03.mozilla.org>
Anne van Kesteren wrote:

> Why is it important the the second styleset declaration is separate and  
> not just merged? I.e. why does
> 
>    styleset: alt-g 1, alt-m 3, curly-quotes 5, code-forms 4 7 9;
> 
> not work? Or
> 
>    styleset: alt-g 1, alt-m 3 / curly-quotes 5, code-forms 4 7 9;
> 
> or something similar?

The question is whether you want multiple @font-feature-values rules to
compound or override.  Consider this scenario:

global.css (linked to in all pages for a given site):

  @font-feature-values Jupiter Sans {
    styleset { alt-Q: 5, chunky-nums: 7; }
  }

localpage.css

  @font-feature-values Jupiter Sans {
    styleset { hip-nums: 13; }
  }

  p { font-variant: styleset(alt-Q, hip-nums); }

If the set of named values compounds (rather than *replacing* all other
named values), then authors can tweak values for a given page.  In
general, I don't think multiple rules are needed but I can definitely
see cases for large sites where they would be needed.

> The minutes also mention a more constrained proposal by Bert, that was
> not dismissed, and seems simpler for authors, but not presented as an
> option here. 

Bert's comments in the minutes were [1]:

> I also don't like the fact that the value names are author-created,
> not standardized.
> 
> There was another proposal for just turning on variants inside of a
> @font-face rule, so you could just define several font names with
> particular variants baked in.

Bert's referring to the ability to define @font-face rules with
explicit font-variant settings enabled by default.  

  @font-face {
    font-family: Jupiter Sans;
    src: url(JupiterSans.woff) format('woff');
    font-variant: styleset(5, 13);
  }

If this is the only way of using these font-specific alternates then the
added named-value syntax wouldn't really be needed.  But requiring the
use of @font-face rules to access alternates is somewhat cumbersome. It
makes sense for general defaults for a given font but not for all use
cases.  For each possible combination of alternates, authors would need
to create an @font-face rule rather than just changing a simple property
setting.  With named values, font-specific property settings can be used
in a way that works in fallback situations; if the values aren't defined
for fallback fonts, they are ignored.

Cheers,

John Daggett

[1] http://www.w3.org/2010/11/02-CSS-minutes.html#item03
Received on Monday, 15 November 2010 12:14:42 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:34 GMT