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

[css3-fonts] Names of 'font-variant-*' properties and relationships to OT features

From: Christoph Päper <christoph.paeper@crissov.de>
Date: Thu, 10 May 2012 17:02:19 +0200
Message-Id: <6BB354DC-0F6A-4548-A5D1-216090DE3F42@crissov.de>
To: www-style list <www-style@w3.org>
The name of the property currently called ‘font-variant-position’ is already noted as an issue. I’d like to support that and extend it. The sub-properties of ‘font-variant’ should uniformly describe either what types of characters they are applied to or what effect they have on characters they are applied to.

  Current name               Applies to        Effect

  ‘font-variant-position’    all chars         glyph substitution or synthesis
  ‘font-variant-ligatures’   some char pairs   glyph substitution
  ‘font-variant-caps’        lowercase chars   glyph substitution or synthesis
             … ‘all-*’       bicameral chars   glyph substitution or synthesis
             … ‘unicase’     bicameral chars   glyph substitution
             … ‘titling-*’   uppercase chars   glyph substitution
  ‘font-variant-numeric’     digits            glyph substitution
             … ‘frac’        digits + solidus  glyph substitution or composition
  ‘font-variant-alternates’  all possible[1]   glyph substitution
             … ‘contextual’  some char pairs   glyph substitution
             … ‘swash’       uppercase[2]      glyph substitution
             … ‘ornament’    bullet            glyph substitution
             … ‘annotation’  digits mostly     glyph substitution
  ‘font-variant-east-asian’  some sinograms    glyph substitution
             … ‘ruby’        syllabograms      glyph substitution

[1] ‘stylistic’, ‘styleset’ and ‘character-variant’ may apply to any character or character sequence and require ‘@font-feature-values’. ‘historical-forms’ may apply to any character, too, but is predefined in the font.
[2] Swashes mostly apply to initial uppercase, but also initial and final lowercase or caseless, and also medial, especially with ascender or descender.

You see that …
— the sub-/superscript property is the only one that applies to every single character. The other properties either just apply to a subset (and may need to synthesize) or it’s up to the font which characters are affected in which combination. I already wrote in my last mail that I think it shouldn’t be used with HTML’s ‘sub’ and ‘sup’ elements, but with one of their ancestors.
— sometimes it depends on the value which type of characters a property applies to.

Basing properties on affected characters would yield something like this:

  ‘font-variant-position’: normal | auto | none /* ‘init’, ‘fina’ … */
    ‘font-variant-initial’: normal | auto | swash || <feature-value-name>#
    ‘font-variant-medial’: /* ditto */
    ‘font-variant-final’: /* ditto */
    ‘font-variant-free’: normal | auto | annotation || ornament || <feature-value-name>#

  ‘font-variant-case’: normal | small-caps | petite-caps | unicase | titling
    ‘font-variant-cased’ or                         /* may include digits */
    ‘font-variant-bicameral’: normal | small-caps | petite-caps | unicase
    ‘font-variant-lower’: normal | small-caps | petite-caps /* fall back to each other */
    ‘font-variant-upper’: normal | small-caps | petite-caps | titling
                   /* … | swash | <feature-value-name># */
    ‘font-variant-punctuation’: normal | [titling || <feature-valuename>]#
    ‘font-variant-parentheses’: normal | auto /* grow to enclosed line-height */

  ‘font-variant-digit’: normal | [ [proportional|monospace] || [uppercase|lowercase] ]
                        [, slashed-zero ]? [, ordinal ]? [, annotation ]?

  ‘font-variant-index’: normal | auto | sub | super /* depends on markup + magic */
    ‘font-variant-subscript’: normal | alternate    /* depends on ‘vertical-align’ */
    ‘font-variant-superscript’: normal | alternate  /* depends on ‘vertical-align’ */

  ‘font-variant-bullet’: normal | auto | <feature-value-name>#
/* Level 4, partially AAT, may conflict with ‘@text-transform’:
  ‘font-variant-quotes’: normal | auto     "'it's'" → “‘it’s’”, reuse ‘quotes’ property
  ‘font-variant-dashes’: normal | auto     --- -- -1 → — – -1
  ‘font-variant-arrows’: normal | auto     => -> → ⇒ →
  ‘font-variant-dots’: normal | auto       ... → …
  ‘font-variant-spaces’: normal | auto     non-breaking, thin, french …
  ‘font-variant-emoticons’: normal | auto  :-) → ☺
  ‘font-variant-operators’: normal | auto  * / - =< → × ÷ - ≤
  ‘font-variant-math’: normal | can-of-worms
*/
  ‘font-variant-east-asian’ or      /* not ‘font-varant-ideograph’ */
  ‘font-variant-sinogram’: normal /* trust Unicode */
                         | auto /* trust content language */ 
                         | [ simplified | complex /* depend on font */
                           | korean | vietnamese
                           | [traditional | reformed]? chinese 
                           | [1978|1983|1990|2004]? japanese /* jisXY */
                         ]# /* preference and fallback order */

  ‘font-variant-syllabogram’: normal | annotation  /* depends on markup */
   or
  ‘font-variant-ruby’ or
  ‘font-variant-annotation’: normal | alternate   /* depends on ‘display’ */

  ‘font-variant-digraph’ or 
  ‘font-variant-sequence’: normal | separate /* fi → fi */ | [contextual]? [alternates]? 
                         [required || common || discretionary || historical]? ligatures 
    ‘font-variant-fraction’: normal | diagonal | stacked /* fall back to each other */

  ‘font-variant-style’: normal | <feature-value-name>#

Every occurrence of ‘alternate’ may be replaced by ‘auto’.

Basing properties on their effect would look simple property-wise, but horrible otherwise:

  ‘font-variant-substitution’: /* try your imagination */
  ‘font-variant-synthesis’:   subscript || superscript || [all]? [small-caps|petite-caps]
  ‘font-variant-composition’: diagonal-fraction | stacked-fraction

I really hate to suggest (again) a major overhaul of this module, because the editor has done a great job introducing and illustrating the concepts and collecting what Open Type offers, but I firmly believe the structure is not well enough thought out – or systematic enough – for authors and real usecases. 

As far as I know current implementations are limited to ‘font-feature-settings’, so it’s not too late to change, although it soon may be. Therefore now is the time!
Received on Thursday, 10 May 2012 15:02:32 GMT

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