[css-fonts-4] font-feature-settings don’t cascade

[nicksherman]

Currently, font-feature-settings cancel each other out, making it impossible to apply them with abstract logic.

For example, say I want to achieve the following:

• Every div uses stylistic set 1.
• Every p uses stylistic set 2.
• Every p inside a div uses both stylistic sets 1 and 2.

Currently, this requires some repetition:

div { font-feature-settings: "ss01";}
p { font-feature-settings: "ss02";}
div p { font-feature-settings: "ss01", "ss02";}

Ideally – keeping in the cascading spirit of CSS – font-feature-settings could be inherited and combined, avoiding redundancy while allowing more logical abstraction. Like so:

div { font-feature-settings: "ss01";}
p { font-feature-settings: "ss02";}

[dbaron]

Two comments here:

1. We've talked about an “additive cascade” concept for a while. This is one of a number of places where it would be useful.
2. This is also one of the reasons that the font-variant-* properties are preferable to the low-level font-feature-settings.

[nicksherman]

@dbaron Yeah, the font-variant-* properties work well for this, but as you probably know they only cover a portion of all the available font feature settings.

[svgeesus]

This is also one of the reasons that the font-variant-* properties are preferable to the low-level font-feature-settings.

And this is one reason I would like to see other browsers coming up to the same level that Firefox has on font-variant-* because font-feature-settings is more widely implemented but should be kept for rarer, special cases. And it is the same code under the hood, to talk to the font engine, once the CSS specifics of parsing are dealt with.

Which is not to say that the additive cascade idea isn't needed.

[jpamental]

I'd chime in here that even as someone who is pretty familiar with using OT features on the web, I had opted for font-feature-settings because I saw it as more widely supported and didn't know the difference until a half-hour ago between them and font-variant-*

That said I've promised @litherum to mend my ways and learn the difference and write about it. If it was supported and we had more people writing about it (raises hand) then we'd be able to achieve what @nicksherman wants by something like this, right?

div { font-variant-alternates: styleset("ss01");}
p { font-variant-alternates: styleset("ss02");}

[Crissov]

@jpamental No. Read up on @font-feature-values.

@font-feature-values MyFont {
  @styleset { my-keyword: 1; another-keyword: 2; }
}
div { font-variant-alternates: styleset(my-keyword);}
p { font-variant-alternates: styleset(another-keyword);}

[jpamental]

Thanks @Crissov - I had missed that first part (@font-feature-values) - unfortunate that it's only implemented in FF and Safari so far, but it's a start!

That said, it does seem if font-variant-alternates and @font-feature-values were both fully implemented, it should achieve what @nicksherman is describing, yes?

[Crissov]

Yes

[litherum]

WebKit doesn't implement @font-feature-values. See also: #577

[kennethormandy]

I didn’t see this discussion before, but if other people find it looking for a solution in the meantime, this one of the reasons I made Utility OpenType which mitigates this somewhat with CSS feature qeuries:

.liga {

  /* Gracefully degrade to `font-feature-settings` to
   * avoid disrupting the OpenType feature cascade
   * when possible. */
  @supports not (font-variant-ligatures: common-ligatures) {
    font-feature-settings: "liga";
  }

  /* IE doesn’t support @supports; explicitly use
   * the prefixed version. */
  -ms-font-feature-settings: "liga";

  /* Best case scenario, just use `font-variant-*`. */
  font-variant-ligatures: common-ligatures;
}

This example is a bit contrived since ideally liga is already on, but I applied the same idea to the other OpenType features that have lower level properties. As Nick mentioned in the first comment, there are still some issues that this can’t get around, and mixing these class names and Stylistic Sets is one of them.

---

One other cascade-related issue I haven’t been able to get around is mixing spans and the Contextual Alternates feature.

A basic example:

<style>
.calt { font-feature-settings: "liga", "calt"; }
</style>
<p class="calt">
  <span>g</span><span>l</span><span>o</span><span>v</span><span>e</span><span>s</span>
</p>

Even though the Contextual Alternates feature is applied to the paragraph, each letter in the span will act as though it’s the first in the phrase, even if there is a calt feature that should swap to an alternate glyph. This can be a problem for script fonts in particular.

For a weird but real-world example, I recently designed a sketch-y emoji/icon set for a magazine, and I made alternates for the icons. So, when they use it, if they use the same icon in a row, it uses a different alternate drawing so it looks more like a sketch:

This is using the Contextual Alternates feature (which I turn off and then on again when I highlight the text in that gif) and works great. The other designer I was working with designed a layout that changed the colour of each of these glyphs.

This isn’t a problem if they are all the same:

…but once you wrap each in a span they are each treated as their own phrase, even though the Contextual Alternates feature is applied to the parent (or even not applied at all, since it should be a browser default):

I’m not even sure if this would be considered incorrect, but it definitely seems related to the question of how the cascade of OpenType features works or should work.

[nicksherman]

@kennethormandy I believe the <span> issue you described is less about cascading and more about spans breaking the contextual glyph sequences for OpenType features in some (all?) browsers. I haven't tested it recently, but in the past I ran in to problems where an OpenType substitution would be broken if any of the characters that triggered it were wrapped in spans.

Perhaps the CSS spec should be more explicit about how user agents should handle contextual glyph substitution when there are spans involved. But that probably deserves its own separate issue.

[fantasai]

@nicksherman You mean like this? :) https://drafts.csswg.org/css-text-3/#boundary-shaping

[litherum]

WebKit has an ancient bug about this: https://bugs.webkit.org/show_bug.cgi?id=6148