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

Change sub & sup? #48

Open
jensimmons opened this issue Jul 29, 2019 · 11 comments
Open

Change sub & sup? #48

jensimmons opened this issue Jul 29, 2019 · 11 comments

Comments

@jensimmons
Copy link
Owner

I'm in the middle of something... and tripped down multiple rabbit holes that brought me to this:

sub { font-variant-position: sub; } 
sup { font-variant-position: sup; }

The CSS WG wrote about it here: https://wiki.csswg.org/faq

Let's consider. Meanwhile, back out of this rabbit hole for me, so I can go back down the other one....

@dbaron
Copy link

dbaron commented Jul 29, 2019

I believe this doesn't have good fallback for either:

  • nested sub or sup, or
  • superscripts or subscripts that contain some characters for which the font has special glyphs and some for which the font doesn't (or some combination like that; I forget the exact rules)

The CSS WG had a huge debate when it was designing this feature about trying to make it work for better fallback so that it could be more usable by default -- I think we ended up bailing for various reasons -- a combination of the complexity it would have, and also the fact that font metrics for superscript/subscript position and size don't actually match the font's special superscript/subscript glyphs.

@scottkellum
Copy link

scottkellum commented Jul 29, 2019

I wish there was a way to query font feature and variation settings because not all fonts support subscript and superscript. It would be cool if you could do something like:

@supports (font-variant-position: sup) {
  sup {
    font-variant-position: sup;
  }
} @else {
  font-size: 0.6em;
  vertical-align: super;
}

But this queries if the browser can support that CSS property/value, not if the element you are targeting has a font loaded that supports that property/value.

@jensimmons
Copy link
Owner Author

You raise an interesting question for the CSSWG, @scottkellum — could there be a new media query invented that would check the font for something, and run code only if that particular thing were supported in the font. I'm not sure that's possible, because the font likely hasn't finished loading before the CSS is parsed, and no one wants to make things slower or dependent on slow stuff. We could raise this as an issue though, and see if it might so anywhere (maybe my first thought is wrong).

Meanwhile, David's comments remind me of something @mirisuzanne and I were talking about a few weeks ago. Rather than write about it here, however, I'm going to open it as a meta-issue. (So it's not lost down in these comments).

@scottkellum
Copy link

I would imagine it would work similar to Adobe’s Web Font Loader but query features instead of specific fonts.

@jensimmons
Copy link
Owner Author

Right — of course querying features, not specific fonts. But in order to ask the font "do you do this?" the font would have to be loaded. And that takes some time. Meanwhile the CSS has already parsed and made all its decisions about what to do or not do. We're talking about milliseconds here, but every millisecond counts. When Mozilla overhauled the CSS parsing and rendering engine in 2017, it made Firefox much faster. Parsing can't wait for any file to download. David though, would understand this far better than I — whether or not something is possible here to query a font's features. I have a vague hand-wavy understanding.

Why don't you open an issue on CSSWG's repo, Scott, and we can discuss it there.

@dbaron
Copy link

dbaron commented Jul 29, 2019

For what it's worth, one of the major discussions the CSS WG had about this feature was this one in Kyoto discussing this proposal to address some of the issues with font-variant-position: sub/sup. I think there were other later discussions as well, though.

@dbaron
Copy link

dbaron commented Jul 29, 2019

There was also this later discussion on what happens when these subscripts/superscripts are underlined; I forgot about that issue!

@jensimmons
Copy link
Owner Author

Right now (at least in Firefox), the browser's CSS for sub and sup is

sub {
    vertical-align: sub;
    font-size: smaller;
}
sup {
    vertical-align: super;
    font-size: smaller;
}

To my eye, the "smaller" doesn't really get small enough.

Demo: https://codepen.io/jensimmons/pen/pozaZWL?editors=1100

Something to look at more later...

@scottkellum
Copy link

scottkellum commented May 5, 2021

What I’m using in projects these days:

sup, sub {
  vertical-align: baseline;
  font-size: 1em;
  font-variant-position: super;
}
sub {
  font-variant-position: sub;
}

Edit: Firefox is the only browser that supports the standalone font-variant-position property and font-feature-settings should be used in production.

@mirisuzanne
Copy link
Collaborator

Setting font-size to 1em is an interesting choice - kinda the opposite of @jensimmons sense that smaller wasn't small enough.

@scottkellum
Copy link

@mirisuzanne My view is that you shouldn’t be chaining the font size at all with sub and sup if your font supports it. Subscript and superscript is already baked into many fonts themselves, and we should be using the subscript and superscript from fonts instead of re-styling our own.

This is also why I proposed a test to see if a font had sub and superscript features earlier in this thread. If a font does not support these features then yes, you would need to style your own sub and superscripts.

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

No branches or pull requests

4 participants