Skip to content

Instantly share code, notes, and snippets.

@DanCouper
Last active August 29, 2015 13:56
Show Gist options
  • Save DanCouper/8998895 to your computer and use it in GitHub Desktop.
Save DanCouper/8998895 to your computer and use it in GitHub Desktop.
Various notes on :advanced font rules, many not widely implemented.

Order of precedence in application of feature

General and font specific font feature property settings are resolved in the order below, in ascending order of precedence. This ordering is used to construct a combined list of font features that affect a given text run.

  1. Font features enabled by default, including features required for a given script.
  2. If the font is defined via an @font-face rule, the font features implied by the font-variant descriptor in the @font-face rule.
  3. If the font is defined via an @font-face rule, the font features implied by the font-feature-settings descriptor in the @font-face rule.
  4. Font features implied by the value of the ‘font-variant’ property, the related ‘font-variant’ subproperties and any other CSS property that uses OpenType features (e.g. the ‘font-kerning’ property).
  5. Feature settings determined by properties other than ‘font-variant’ or ‘font-feature-settings’. For example, setting a non-default value for the ‘letter-spacing’ property disables common ligatures.
  6. Font features implied by the value of ‘font-feature-settings’ property.

This ordering allows authors to set up a general set of defaults for fonts within their @font-face rules, then override them with property settings for specific elements. General property settings override the settings in @font-face rules and low-level font feature settings override ‘font-variant’ property settings. For situations where the combined list of font feature settings contains more than one value for the same feature, the last value is used. When a font lacks support for a given underlying font feature, text is simply rendered as if that font feature was not enabled; font fallback does not occur and no attempt is made to synthesize the feature except where explicitly defined for specific properties.

How the browser should render a given font

Case Sensitivity: the browser should match case-insensitively, but note that browsers will match @font-face and fonts available locally, and that care should be taken to ensure that the name used has a character set consistent with the family name. Not doing this can cause problems - the w3c use the example of specifying a font name, and using combining diacritical characters, wheras the font specified by the author uses a precomposed character: the browser will not render the font, as it will not match.

Unicode range:

w3c notes -

Multiple @font-face rules with different unicode ranges for the same family and style descriptor values can be used to create composite fonts that mix the glyphs from different fonts for different scripts. This can be used to combine fonts that only contain glyphs for a single script (e.g. Latin, Greek, Cyrillic) or it can be used by authors as a way of segmenting a font into fonts for commonly used characters and less frequently used characters. Since the user agent will only pull down the fonts it needs this helps reduce page bandwidth.

This could be used in regards to smallcaps/lining figures etc. Care would need be taken, but it is extremely doable.

Font Synthesis

The font-synthesis rule prevents browser agents from synthesising bold or oblique faces when the family lacks a bold or oblique. This synthesis will, almost universally, ruin fonts. Contender for global?


*
*:before,
*:after {
  font-synthesis: none;
}

Font Features

font-variant prior to CSS3 (and opentype support) simply selects between normal and smallcaps. The browser will synthesize false smallcaps if a. the font does not actually have smallcaps, and b. if the browser does not support CSS3 opentype features. This is non-optimal, to an even greater degree than synthesized bold or oblique faces. Synthesized smallcaps will look too light in comparison to the rest of the text.

A better alternative would possibly be to generate a smallcaps version of the font with smallcaps in place of upper- and lower-case letters (to prevent capitals within smallcaps text). This can then be loaded in via @font-face, with the same name and the font-variant explicitly set to smallcaps. This has obvious Difficulties re. integration with the workflow/build process.

CSS3 extends font-variant to provide high-level shorthand control over other features such as stylesets or ligatures.

font-feature-settings provides low-level control for special cases. It take a string or strings of case-sensitive four-character long opentype feature tags. It can be used to override font-variant values - even if font-variant is set to normal, font-feature-settings definitions will still be honoured if applicable.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment