font-feature-settings: What is the correct syntax?

Question

I purchased a webfont that supports some open type features and of course I want to use them.
Unfortunately, I wasn't able to find a source online that explains the best way to use the syntax - it seems to me that font-feature-settings are another example of prefix hell.

At the moment I have it written like that but I am not sure if it covers really all browsers that support those features.

.element {
    -webkit-font-feature-settings: "kern" 1, "liga" 1, "case" 1;
       -moz-font-feature-settings: "kern=1", "liga=1", "case=1";
       -moz-font-feature-settings: "kern" on, "liga" on, "case" on;
        -ms-font-feature-settings: "kern" 1, "liga" 1, "case";
         -o-font-feature-settings: "kern", "liga", "case";
            font-feature-settings: "kern", "liga", "case";
}

More specifically, the -moz syntax seems strange. Some sources claim that this is the syntax to be used:

-moz-font-feature-settings: "liga=1";  /* Firefox 14 and before */
-moz-font-feature-settings: "liga" on; /* Firefox 15 */

Others do it simply like this:

-moz-font-feature-settings: "cswh=1";
-moz-font-feature-settings: "cswh";

The same goes for -webkit; some write it like that:

-webkit-font-feature-settings: "liga" on, "dlig" on;

While others do it like this:

-webkit-font-feature-settings: "liga", "dlig";

Or like this:

-webkit-font-feature-settings: "liga" 1, "dlig" 1;  

And on top, there is also text-rendering: optimizelegibility; which seems to be the same as "kern" and "liga", at least in webkit browsers.

So, what is the correct, bulletproof way to use Open Type font features on the web in 2013?

Lonely

The spec does not make any mention of "feature=value" syntax in the actual property value, so I'm guessing the old Mozilla syntax is non-standard. All three WebKit examples that you mention are equivalent as far as the draft spec is concerned. – Premises

Answer 1

Well, the best place to look for how 2013 web features should work would be the W3 CSS3 Specification:

If present, a value indicates an index used for glyph selection. An value must be 0 or greater. A value of 0 indicates that the feature is disabled. For boolean features, a value of 1 enables the feature. For non-boolean features, a value of 1 or greater enables the feature and indicates the feature selection index. A value of ‘on’ is synonymous with 1 and ‘off’ is synonymous with 0. If the value is omitted, a value of 1 is assumed.

This means that "liga" 1, "liga" on and liga all do the same thing.

As BoltClock mentioned in his comment on the question, "feature=value" isn't valid syntax, and seems to be something specific to Firefox.

Opera and IE (<10) do not support font-feature-settings at all, so the -o-* and -ms-* attributes are presumably useless.

Overall, a working syntax for all currently supported browsers would appear to be:

.element {
    -webkit-font-feature-settings: "kern", "liga", "case"; /* No variation */
       -moz-font-feature-settings: "kern=1", "liga=1", "case=1"; /* Firefox 4.0 to 14.0 */
       -moz-font-feature-settings: "kern", "liga" , "case"; /* Firefox 15.0 onwards */
       -moz-font-feature-settings: "kern" 1, "liga" 1, "case" 1; /* Firefox 15.0 onwards explicitly set feature values */
            font-feature-settings: "kern", "liga", "case"; /* No variation */
}

Instinct

If all browsers require prefixes but support the syntax equally according to the grammar, this could work, but what we aren't sure of is which values (out of off/on, 0/1 and no value at all) are supported by which versions of which browsers. That could be problematic. – Premises

From what I can gather, Firefox 4.0 through to 14.0 uses "kern=1", but 15.0 onwards use just "kern" ([1/on][0/off]). Not sure why they didn't simply follow the specification in the first place, however. The note at the bottum of caniuse.com/font-feature suggests that -webkit has used the same syntax all the way through. – Instinct

Internet Explorer 10 has a valid implementation of font-feature-settings. – Instinct

That's good to know (assuming caniuse.com is accurate on that account - which it usually is!). I'm not familiar with the history of font-feature-settings either - it could have been an early experiment Mozilla partook before proposing it to spec, or it could have been something else. – Premises

It appears -ms-font-feature-settings did exist at one point according to MSDN. It could have been used by the pre-release builds before being unprefixed in the stable release, as with several other modules. – Premises

Answer 2

http://hacks.mozilla.org/2010/11/firefox-4-font-feature-support/ would probably be a good place to start, as well as the specification itself.

It should also be noted that you won't get a fully bulletproof way of using font-features in the sense that it would work across all browser. According to caniuse, font-features has kind of sketchy support (nothing at all in Opera, nothing prior to IE10, nothing in most of the mobile browsers, partial and prefixed in what's left), in part due to it still being in "Working Draft" status, which means there's still a chance it will change. Therefore, it would be a good idea to not depend on this feature quite yet, and expect that it's just not going to work in all browsers.

On another note, since you mentioned "prefix hell" (which actually isn't that bad - prefixes are meant to be dropped over time; did you know you no longer need prefixes at all for border-radius unless you're stuck supporting truly ancient browsers?) - you might want to look into one of the CSS preprocessors, such as LESS or Sass. These tools can help you with the cutting-edge CSS by putting in the prefixes and correct syntax for you, while you keep your source clean with declarations that follow the W3C standards.

Score

"prefixes are meant to be dropped over time" It took more than 10 versions of Firefox over 6 years for -moz-border-radius to be dropped. That's an astoundingly long time. – Premises

@Premises - According to caniuse, Firefox dropped it as a requirement in version 4. It's possible that future versions still supported it, but it hasn't been necessary for some time. – Score

Yeah but they had to continue supporting it for several years because the unprefixed version was missing from a worrying number of sites even after it was deprecated. It's a real shame, but I guess the way Web development is, we can't really blame either party for not using prefixes properly bringing us where we are today. – Premises

@Premises - That's neither the fault nor the problem of the browser developers, but the people who write the CSS for those sites. Additionally, saying that it took "10 releases", while true, is a bit misleading. Those ten released took only 13 months, which really isn't an unreasonable amount of time in either direction (too long or too short) to update systems that arguably weren't properly future-proofed to begin with. – Score

Well, perhaps -moz-border-radius was a poor example - after all, Mozilla doesn't have nearly as many widely-used prefixes as WebKit does... – Premises

@Premises - Poor example for you, but perfect for my original point in my answer. And Webkit also has a very large number of non-standard stuff, which is their own fault (they've been notorious about actively keeping many of those items out of the standard). – Score