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

Re: [css3-fonts] font-specific feature handling

From: John Daggett <jdaggett@mozilla.com>
Date: Thu, 18 Mar 2010 07:31:27 -0700 (PDT)
To: www-style@w3.org
Message-ID: <518474728.18113.1268922687132.JavaMail.root@cm-mail03.mozilla.org>
In the telecon this week one of the topics discussed [1] was
font-specific font variant features in the CSS3 Fonts spec [2].  The
original post on this is here:

  http://lists.w3.org/Archives/Public/www-style/2010Feb/0244.html

In the current draft some of the 'font-variant-alternates' values take
numeric values to indicate specific variants.  These values are tied
to a specific font.  If fallback occurs, the concern is that those
values will apply to a fallback font and that will lead to "bad"
results:

  body {
    font-family: MyFancyFont, SomePlatformFont;
    font-variant: additional-ligatures styleset(1,3);
  }

Note that for anything other than default glyphs to be rendered in
the fallback font, a given character would have to be missing in the
initial font *and* a variant would have to be available for that
character in the fallback font.

Fantasai and Peter suggested that values that take numerical values
should only be available within @font-face rules and not available in
the general version of the property (the draft spec currently allows
both).  The above example would be instead written as:

  @font-face {
    font-family: MyFancyFont;
    font-variant: styleset(1,3);
  }

  body {
    font-family: MyFancyFont, SomePlatformFont;
    font-variant: additional-ligatures;
  }

In this case, stylesets 1 and 3 are only applied to MyFancyFont (i.e.
ss01 and ss03) and never to a fallback font.

Allowing both gives authors flexibility but I really don't like the
idea of restricting font-specific values to @font-face rules, it makes
normal authoring more cumbersome because an @font-face rule would need
to be defined for *each* combination of restricted values:

  @font-face {
    font-family: MyFancyFont-Ornament1;
    font-variant: ornaments(1);
  }

  @font-face {
    font-family: MyFancyFont-Ornament3;
    font-variant: ornaments(3);
  }

  @font-face {
    font-family: MyFancyFont-Headings;
    font-variant: swash(1) styleset(6);
  }

  @font-face {
    font-family: MyFancyFont-Text;
    font-variant: styleset(2,3);
  }

  p.special:first-letter { font-family: MyFancyFont-Ornament1; }
  p.regular:first-letter { font-family: MyFancyFont-Ornament3; }
  h1, h2 { font-family: MyFancyFont-Headings; }
  p.special { font-family: MyFancyFont-Text; }
  
Dang, that's verbose!  Compare this to using just the general property:

  p.special:first-letter { font-variant: ornaments(1); }
  p.regular:first-letter { font-variant: ornaments(3); }
  h1, h2 { font-variant: swash(1) styleset(6); }
  p.special { font-variant: styleset(2,3); }
 
In general, it's really, really hard to construct an example where
fallback occurs and anything other than the default glyphs are used. 
Most platform fonts lack alternate variants.

Where authors run into the exceptional situation in which fallback
rendering is somehow a problem, the ability to specify font-variant
values in @font-face rules would provide a way to work around these
problems.

I think we're all accustomed to dealing with font stacks and fallback
issues but with downloadable fonts, that's really an old paradigm.  In
a world where web fonts are ubiquitous, an author specifies the font
they want and doesn't worry so much about fallback.  I don't think we
should make authoring more difficult in this situation for the sake of
fallback problems that are theoretically possible but generally don't
occur in practice.

Regards,

John

[1] http://krijnhoetmer.nl/irc-logs/css/20100317#l-117
[2] http://dev.w3.org/csswg/css3-fonts/
Received on Thursday, 18 March 2010 14:32:00 GMT

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