[html] Change default <sup> and <sub> styling?

[domenic]

HTML currently specifies the following default styles for sup and sub:

sub { vertical-align: sub; }
sup { vertical-align: super; }
sub, sup { line-height: normal; font-size: smaller; }

In an article on web typography I just read, it was pointed out that a better default styling would be

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

Is this a change we could consider making? I thought the right people to discuss this with would be the CSSWG, thus I am here.

(One thing that might kill this idea: if this only works on fonts with a sub/sup variant built in, then it seems like it wouldn't be a good default. I wasn't clear from reading the article whether that was the case; it says "That will work fine for browsers that support OpenType", but what about on non-OpenType fonts in browsers that do support OpenType?)

[tabatkins]

Per the spec, if the font doesn't support it, the UA must synthesize appropriately sized/aligned glyphs instead. It's not as good as native support (see the example in the spec) but it's basically equivalent to the current "size it smaller, shift it up/down" styling.

I think the CSSWG would be broadly supportive of this; compat concerns are my only doubt, but they're likely small.

[domenic]

Hooray! I take it from the Agenda+ tag this will be discussed on an upcoming call? I'm happy to write the HTML spec change and web platform tests for this if it gets agreement from implementers in the CSSWG.

[frivoal]

While that is indeed better typography, and I would be happy to switch to that if we could, I don't think this is OK in terms of compat (and semantics) because the possibility of nested sub/sup. While these are not overly common it does exist, and this style change is would induce a rendering with apparently different semantics.

Consider:

2<sup>2<sup>2</sup></sup> = 16

This, even if the typography isn't great, correctly looks like 2^2^2 = 16 with the legacy styling, but would look like 2^22=16 with the proposed change, which is wrong.

I think we can strike a good balance between good typography and good compat by combining the two, using the proposed approach for the first level, and the original one for nesting:

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

:matches(sub, sup) :matches(sub, sup) {  font-size: smaller; }
/* Not using :matches() on the parent in the following 2 rules is intentional,
   it would shift too much. */
sub sub { vertical-align: sub; }
sup sup { vertical-align: super; }

The result is better in the non nested case, and not obviously better or worse in the case of nested subs or nested sups the nested case. It does arguably become somewhat worse when instead of nesting multiple sub or multiple sup, we nest sub in sup or vice versa, but it remains understandable, and that's a pretty rare.

[dbaron]

I remember us having long discussions about font-variant-position at a face-to-face meeting (I think in a room with a wall of windows on just one side that reminded me a little of the appearance of a classroom) about attempting to make the design more suitable for use as default styling of sub/sup. I think I'm probably remembering this discussion about fallback though maybe I'm also remembering is this discussion of their combination with text-decoration. What I don't remember is how those issues all got resolved... and those resolutions affect the suitability of these styles as default styling. I think we ended up not addressing the first issue, at the very least, because we didn't want the complexity?

[dbaron]

Actually, I think another reason we couldn't do the proposal that made nesting work was because it relied on fonts to have font metrics for subscript/superscript position and size that match their variant glyphs for subscripts and superscripts, which turned out not to be the case in the small sample of fonts we checked.

[fantasai]

Florian's explanation is exactly why we didn't make a recommendation to change the default UA style sheet. (There were some proposals on the table that would have made it possible to handle nesting, which would allow this fix, but they weren't accepted due to added complication.)

[litherum]

WebKit does not synthesize font-variant-position: sub and font-variant-position: sup.

[fantasai]

@litherum You should fix that, then. :)

[tabatkins]

Yeah, that's a spec violation, not something you're allowed to just ignore. ^_^

[css-meeting-bot]

The Working Group just discussed Change default <sup> and <sub> styling?.

The full IRC log of that discussion

<dael> Topic: Change default <sup> and <sub> styling?
<dael> TabAtkins: Dominic read an article about <sub> and <sup> and was wondering if he could change html styllesheet to support them instead of the basic way we do. I think it's okay, but we need yes/no from other people.
<dael> florian: There are comments. The problem is when you start nesting.
<dael> TabAtkins: Okay. Reasonable.
<dael> Rossen: Let's put it back to the issue. There's discussion. We'll bring it back next week.
<dael> Rossen: That's the top of the hour.
<dael> Rossen: Thank you everyone, we'll talk next week.
<fantasai> TabAtkins, the short answer to Domenic's question is "no"
<TabAtkins> Yeah, forgot about needing. Makes sense.
<TabAtkins> Could maybe apply it to the first level, and do scaling/shifting for nested stuff, but that's complex.
<fantasai> TabAtkins: There were proposals for that, see dbaron's links.
<fantasai> TabAtkins: They were rejected.
<fantasai> TabAtkins: atm, I think the priority is getting myles to fix synthesis so semantics don't break even in basic cases when the font is missing those glyphs :) :) :)
<zcorpan> dbaron: github-log-bot is not awake?
<zcorpan> at least I don't see any bot comment in https://github.com//pull/1805
<dbaron> github: https://github.com//issues/1888
<dbaron> trackbot, end meeting

[css-meeting-bot]

The Working Group just discussed Change default <sup> and <sub> styling?.

The full IRC log of that discussion

<dael> Topic: Change default <sup> and <sub> styling?
<dael> github: https://github.com//pull/1888
<dael> Rossen_: Anyone want to take this? florian and dbaron were involved, I know. Or myles
<dael> myles: I can summerize.
<astearns> github: https://github.com//issues/1888
<dael> myles: In HTML there's <sup> and <sub> that are defined in UA stylesheet to do vertical align and reduce font size. Now that open type fonts are available it may be that there are specific information in the font for this.
<Chris> q+
<dael> myles: Issue proposes we change UA style sheet to turn on the font features.
<Rossen_> q?
<tantek> perhaps experiment with MathML super/subscripts first?
<dael> fantasai: Problem with this is that it doesn't handle anything that is nested so if you have any elements inside it like something to an exponent and the exponent has an exponent in it the feature won't work. So this breaks cases that would have worked.
<tantek> fantasai's answer makes sense and would likely make a good FAQ in the spec
<dael> fantasai: We had when designing font varient feature it was decided not to do that which is why font spec doesn't recommend this as a replacement. Given that's the case we should advise HTML to not make t his change.
<myles> q+
<dael> florian: I followed up trying to make a hybrid using font features for first level and then fallback for nesting. I'm not sure it handles all cases. If people want to keep i nvestigating if we can write such rules maybe we can look into that. I'm not confident it's sufficient
<Rossen_> ack Chris
<dael> Chris: I think it's a good approach. The PR is sent for tests for CSS 3 fonts actually mentions that. I think it's better to make the single level of nesting use the open type feature which will give you a better result in the common and if you're complex maybe you should use mathML
<tantek> q+ to mention compat just because in case dbaron doesn't :)
<dael> dbaron: I don't think...I think what chris suggests for top level won't work if the font metrics are inaccurate which is common. There's no guar it'll work or that a subscript will align anywhere correct so you could distinguish the super script of a superscript.
<dael> florian: I think it works mostly.
<dael> dbaron: It depends on how well the font metrics match the characters.
<dael> fantasai: It also doesn't handle images in the subscript so I think there's a lot of things that will break.
<tantek> q+ to also mention imma let you finish your UA style sheet proposal but test cases that demonstrate this would be the best thing ever!
<dael> myles: First, I'd like to agree with fantasai and dbaron. Apart from that we would like some ability for the UA to use the glyphs if it can figure out the right way. we don't think this proposal is sufficient, but it is possiblefor a UA to use these gyplhs. This prop i sn't the right way but we'd like some sort of affordance in the future.
<dael> fantasai: But that would require new CSS features. We've discussed that in the past and peopledidn't want to do it. We can re-open those discussions. We should close this req/ and say you can't do that, but if you want to make a bug against Fonts 4 or 5 to make this possible you can do that.
<dael> myles: I agree. This isn't the right place but the goal is noble.
<dael> fantasai: We appriciate the effort to incorporate better typography, but this isn't the right place and it's not able to handle it currently.
<dael> Rossen_: Any other comments or suggestions?
<dael> Rossen_: If not we can close with fantasai's suggested rec.
<tantek> lol when Rossen asks that without checking the queue
<Rossen_> q?
<Chris> q?
<Rossen_> ack myles
<Rossen_> ack tantek
<Zakim> tantek, you wanted to mention compat just because in case dbaron doesn't :) and to also mention imma let you finish your UA style sheet proposal but test cases that demonstrate
<Zakim> ... this would be the best thing ever!
<dael> tantek: A couple of comments. I would suspect that changing this for sub and sup it will break compat in unpredicatbale ways since those tags have been used so long.
<fantasai> tantek's got a good point
<dael> tantek: Second question is, I didn't see a URL to a test case that demos what this would look like old vs new style. I think at a minmum we need that to consider this proposal.
<dael> Rossen_: Anyone have a test case or code that can demo this side by side?
<fantasai> if an author, say, fusses with vertical-align on the superscripts on the page, a font-variant-position--based UA style sheet is going to break that page
<dael> Rossen_: I don't hear any. We can go back to the issue and wait for the people discussing it to see if anything will come through.
<dael> fantasai: I think tantek has a good point about how this has been used a long time. People have tweeked their style sheet to make these tags look better and may be relying on vertical align. We will break pages if we try and change the default stylesheet.
<dael> fantasai: That will apply to any case where we try and make things better unless it's really automagic.
<dael> Rossen_: Anything else on this topic?
<Rossen_> q?
<fantasai> s/vertical align/vertical-align or font-size cascading through/

[svgeesus]

@domenic so as you can see there was discussion, and concerns about web compat particularly for the nested case, but so far no actual resolution. It looks like this will be closed as won't fix because of that web compat issue. Are you okay with that?

[svgeesus]

Closed as won'tfix due to webcompat, commentor @domenic assumed satisfied after 6 weeks.

[dbaron]

For the record, the pair of long F2F discussions around synthesis, nesting, and related topics when we were designing this feature were part 1 and part 2.