Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
nicksherman opened this issue Sep 29, 2016 · 14 comments

Comments

@nicksherman
Copy link

commented Sep 29, 2016

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

This comment has been minimized.

Copy link
Member

commented Sep 29, 2016

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

This comment has been minimized.

Copy link
Author

commented Sep 29, 2016

@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 comment has been minimized.

Copy link
Contributor

commented Sep 29, 2016

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

This comment has been minimized.

Copy link

commented Oct 6, 2016

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

This comment has been minimized.

Copy link
Contributor

commented Oct 6, 2016

@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

This comment has been minimized.

Copy link

commented Oct 10, 2016

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

This comment has been minimized.

Copy link
Contributor

commented Oct 12, 2016

Yes

@litherum

This comment has been minimized.

Copy link
Contributor

commented Oct 13, 2016

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

@kennethormandy

This comment has been minimized.

Copy link

commented Oct 18, 2016

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:

sad-randomisation-illustrator

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:

screenshot 2016-10-17 17 03 12

…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):

sad-randomisation-browser

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

This comment has been minimized.

Copy link
Author

commented Oct 18, 2016

@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 it's own separate issue.

@fantasai

This comment has been minimized.

Copy link
Collaborator

commented Mar 30, 2017

@litherum

This comment has been minimized.

Copy link
Contributor

commented Mar 31, 2017

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

@nicksherman

This comment has been minimized.

Copy link
Author

commented Mar 31, 2017

@litherum Good to know, thanks! Perhaps this issue/discussion about features breaking between spans should move to another thread though, since this one was originally about cascading font-feature-settings :)

@fantasai

This comment has been minimized.

Copy link
Collaborator

commented Sep 27, 2017

Closing this one as WONTFIX: this is a known problem with font-feature-settings, which is why we have font-variant-*. Any further work on this would happen through a more generalized additive cascade mechanism, not through changes to font-feature-settings.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
8 participants
You can’t perform that action at this time.