[css-text-decor] Underline position for when decorating box is higher than regular position

[kojiishi]

Test: https://jsbin.com/tewugik/edit?html,output

Gecko positions the underline at the decorating box, while Edge seems to take the lower of the decorating box and the default position of the node.

This difference, along with Blink/WebKit not supporting decorating box yet (crbug.com/1008951), is causing web compat issue for Mozilla. https://bugzilla.mozilla.org/show_bug.cgi?id=1387206 The actual site: https://www.bbc.com/sport/formula1

Can we take Edge's behavior? When actual regressions are known at multiple sites, it'd be difficult for us to match the spec.

/cc @jfkthame

[kojiishi]

Screen shots of the test https://jsbin.com/tewugik/edit?html,output

Gecko:

Edge:

[jfkthame]

I don't think the Edge behavior is desirable here. It would mean that rendering of underlines will be broken in the presence of subscripts: <u>H<sub>2</sub>O</u> will forever look bad.

The inconsistency between behavior when the child box is moved down vs when it is moved up also seems bad. (What about the case of overlines? Would the opposite apply there?)

IMO the spec should be kept as is, because this is the better behavior; it gives authors simple, consistent behavior, and makes it easy to get the result that is usually "right". With the proposed change here, it would become extremely difficult for an author to produce the effect of a continuous underline on text that includes subscripts.

I'm aware there are sites that would exhibit a "regression", but the nature of the regression is that it's a visual glitch rather than something that seriously impacts functionality, and it's easily fixed by correcting the text-decoration styling. It's currently difficult to persuade site authors to care about fixing it because the dominant browser doesn't follow the spec, but if Chrome fixes this behavior, "broken" (not really broken, but visually glitched) sites will suddenly have a greater incentive to correct their content.

[kojiishi]

if Chrome fixes this behavior, "broken" (not really broken, but visually glitched) sites will suddenly have a greater incentive to correct their content.

From my experience in the past, what would happen is that they file bugs against Chromium rather than fixing their sites, and our default choice is to revert the change. Even before that, if regression is known beforehand, our community will not approve shipping the change. It is possible to try to convince the community, but I guess we need more investigations if we want to try that.

Two things I can think of:

• I agree that Edge's behavior on <u>H<sub>2</sub>O</u> isn't optimal, but the spec behavior is not optimal either, looking at the screenshot above, especially with ink skipping on. Are there any other options?
• If there were no other options, I think we should try to convince sites to fix before making the change. Have you contacted to site owners you know look bad with the spec behavior?

[kojiishi]

Also noticed that for <u>H<sub>2</sub>O</u>, really the right thing is font-variant-position: sub, no?

[jfkthame]

Also noticed that for <u>H<sub>2</sub>O</u>, really the right thing is font-variant-position: sub, no?

Possibly, but that doesn't seem to be very widely supported at the moment.

I agree that Edge's behavior on H₂O isn't optimal, but the spec behavior is not optimal either, looking at the screenshot above, especially with ink skipping on.

IMO the spec behavior is the most reasonable result: the line must be uniform across the entire decorated box. If an author expects to have a lot of subscripts, and doesn't like how that interacts with ink-skipping, the two options would be to turn off skipping (so that the underline cuts through the subscripts), or to use text-underline-position: under or text-underline-offset to move the line lower for all the content.

What is categorically wrong, IMO, is for the line to jump up and down on baseline-shifted children of the decorated box. If that result is desired, the decoration should be applied separately to each of the child elements.

what would happen is that they file bugs against Chromium rather than fixing their sites

I'm sure that is true, just as they file bugs against Firefox today. But if Chromium (in addition to Firefox) provides clear messaging that "this is the correct behavior, and if your site looks bad, it's on you to fix it" there will be a much stronger incentive than when it's only Firefox trying to hold that line.

Have you contacted to site owners you know look bad with the spec behavior?

Yes, at least in some cases; I'm afraid I don't know details of how many such contacts there have been, or how often it has led to a site being fixed. In the case of the BBC site reported in https://bugzilla.mozilla.org/show_bug.cgi?id=1584348, for example, the problem is still present. I suspect that if their site started looking bad in Chrome, however, they'd probably get around to fixing it.

Whether you could convince them to fix it before Chrome actually ships a change that "breaks" their site is more questionable, I guess. People love to put things off for another day...

[faceless2]

Re. font-variant-position: sub, Florian covered this at https://wiki.csswg.org/faq

For what it's worth I agree with @jfkthame. I don't see how you can change the behaviour to match Chrome's rendering without breaking Gecko's rendering (and also our rendering) in the process.

[css-meeting-bot]

The CSS Working Group just discussed Underline Position for decorating box.

The full IRC log of that discussion

<fantasai> Topic: Underline Position for decorating box
<fantasai> github: https://github.com/w3c/csswg-drafts/issues/5002
<TabAtkins> fantasai: undeline position requires udnerline to not move
<TabAtkins> fantasai: If the underline cuts thru text, the browser should have chosen initial position better
<TabAtkins> fantasai: but it shouldn't break it and shift some of them
<TabAtkins> fantasai: firefox avoids splitting. could be smarter about positioning, but it works
<fremy> q+
<TabAtkins> fantasai: but other browsers break the underline depending on vertical-align
<TabAtkins> iank_: our most recent beahvior is [missed]
<dbaron> s/[missed]/in Chrome Canary but not Chrome Stable/
<TabAtkins> iank_: I believe our current canary matches firefox in this case
<dbaron> iank_: When we filed this issue we were only investigating the issue.
<TabAtkins> iank_: We'll take the dominant baseline
<TabAtkins> iank_: so this should get us similar to firefox
<TabAtkins> fremy: our behavior we had with edge was intentional
<TabAtkins> fremy: woudln't break the line when the text was above the natural baseline, but would when it went lower
<TabAtkins> fremy: you never want underline to be striking thru text
<TabAtkins> fremy: but it does mean that with the new ink-skipping beahvior, it's probably not as bad to have the line go thru the text, since it doesn't visually cross it actually
<TabAtkins> fremy: so even tho i'd initially have said the edge behavior was what authors want, these days since we have ink-skipping the "always just use one baseline" is better
<TabAtkins> fremy: espeically if it's simpler and matches impls
<Rossen_> q?
<Rossen_> ack fremy
<TabAtkins> fantasai: So fremy i think you're proposing the spec doesn't change, and we encourage that the underline doesn't move for subscripts, but instead ink-skips as normal
<TabAtkins> fremy: I think ink-skipping is enabled by default?
<TabAtkins> fantasai: there's a handful of cjk characters that don't ink-skip, becuase they caused too much
<TabAtkins> fantasai: but i think they're not frequently used as subscripts
<TabAtkins> fremy: i think the edge issue was to break the baseline if it didn't ink skip, since we do ink-skip now that's not necessary
<TabAtkins> fantasai: So if you turn off skipping, should the browser be shifting baselines for subscripts?
<TabAtkins> fremy: I vote yes
<TabAtkins> jfkthame: I vote no, authors ahve properties they can use to control that
<TabAtkins> fremy: can't do that per span, can't affect parent's position
<TabAtkins> iank_: waht was edge's beahvor?
<TabAtkins> fremy: You draw the baseline at dominant position, but i fyou have text that would cross the underline, you break it and move it down for the text
<TabAtkins> iank_: so this would only be when they cross the characters
<TabAtkins> fremy: yes
<TabAtkins> iank_: I checked with koji, he says he'd prefer edge's beahvior here
<TabAtkins> iank_: I just loaded up edge behavior, it seems resilient
<Rossen_> q?
<TabAtkins> florian: I think if the author has sub or super they need to wkr around, they can use -position to work around it
<TabAtkins> florian: and we have :has() now so you can do em:has(sub)
<TabAtkins> fremy: it might only be on one lie
<TabAtkins> fremy: can't guarantee positioning even with text-underline-position
<TabAtkins> fantasai: I think authors want either skipping character or shifting the underline, don't think they want breaking
<TabAtkins> iank_: i don't particiularly like current firefox impl for this case
<TabAtkins> edge's behavior is resilient to these situations
<TabAtkins> fremy: not drawing underline on characters below baseline is a risk you don't draw at all, if an entire line is subbed
<astearns> would prefer an implementation that would set the baseline per spec and low enough for all spans on a line
<Rossen_> q?
<TabAtkins> iank_: I think only us and gecko have this behavior. i think we'd be willing to switch to edge's
<TabAtkins> iank_: what do daniel or jonathan think?
<TabAtkins> jfkthame: seems to be that gecko's behavior (has been there for many years) is fundamentally the right thing, and i'd prefer not to change it
<TabAtkins> iank_: why do you think it's right?
<TabAtkins> jfkthame: I think when an underline is specified on an element, it should be a continuous line, it shouldn't move about for some elements
<dholbert> i defer to jfkthame, (& haven't fully paged this topic in)
<TabAtkins> iank_: even if it obscures the subelements?
<TabAtkins> jfkthame: Sure, don't put lines on top of text, that's bad authoring
<TabAtkins> jfkthame: i think authors have neough control to do sensible things
<astearns> q+
<TabAtkins> iank_: I think it's quite common to get into this case
<TabAtkins> iank_: And to get yourself out o fit again by using additional elements
<TabAtkins> jfkthame: you mean common due to <sub>?
<TabAtkins> iank_: yeah you don't need to use any css to get into this
<Rossen_> ack astearns
<florian> q+
<TabAtkins> astearns: jonathan, would you be at all interested to move the underlie down when there's subscript, so there's a continuous line?
<TabAtkins> jfkthame: i think we could consider, and think spec currently allows for that
<TabAtkins> jfkthame: have some hesitation - if you underline some text that's broken across several, and sub is on one line, does it get a diff position from the other lines? maybe weird, but could think about it
<astearns> s/there’s a continuous line/there’s a continuous line for all the spans?/
<TabAtkins> iank_: Yeah I think shifting the whole thing isn't a good behavior
<Rossen_> a?
<Rossen_> q?
<TabAtkins> iank_: I think solution is to either drop the baseline entirely or have edge html's beahvior
<TabAtkins> fantasai: Spec did specify that kind of auto behavior in the past
<TabAtkins> fantasai: for l3 we made it up to the UA
<TabAtkins> fantasai: there used to be text specifying to move it on a per-line basis
<Rossen_> ack dbaron
<TabAtkins> dbaron: My memory of th espec was the opposite - it spec'd moving all the lines. i think that's harder but better behavior
<TabAtkins> dbaron: Also, in response to jonathan, another way for authors to hit this case is variabiity between fonts
<TabAtkins> dbaron: can hit it on some machines but not others due to font variations
<TabAtkins> dbaron: so this should work well as part of css's robustness to unexpected font metrics
<Rossen_> ack florian
<TabAtkins> florian: don't remember history, but spec as is today in position and offset, has a default of auto that allows for moving it down
<fantasai> “In determining the position of and thickness of text decoration lines, user agents MAY consider the font sizes of and dominant baselines of children. Of course, user agents MAY ignore children in these determinations. Such an averaging is done on a line per line basis.”
<TabAtkins> florian: but neither speaks to per-element or per-fragment
<fantasai> https://www.w3.org/TR/2003/CR-css3-text-20030514/#text-decoration-overview
<TabAtkins> florian: so currently ambiguous.
<Rossen_> a?
<Rossen_> q?
<TabAtkins> florian: maybe we start with more permissive version that allows either, and revisit in a bit to see if ther'es agreement?
<TabAtkins> florian: could say that browsers *may* do it on per-fragment
<fantasai> “In determining the position and thickness of text decoration lines, user agents may consider the font sizes and dominant baselines of descendants, but for a given element's decoration must use the same baseline and thickness on each line.”
<TabAtkins> florian: but not obliged to if it's bad
<fantasai> https://www.w3.org/TR/2010/WD-css3-text-20101005/#decoration
<TabAtkins> iank_: So allow both edge's and firefox's rednering?
<TabAtkins> florian: no. say you have a subscript in a long span. on first line you have a continuous line; it might be shifted down if the sub is there.
<TabAtkins> florian: So shift for the entire elmenet, but allow it to be per linebox fragment. not edge html style
<TabAtkins> iank_: don't think it's necessarily what devs expect
<TabAtkins> florian: will be odd if you ahve a multiline span to see the underline shifted on lines without a sub
<TabAtkins> iank_: i don't think either option is good
<TabAtkins> iank_: Both will look visually odd
<TabAtkins> fremy: don't like shifting per line either
<TabAtkins> Rossen_: so if we move forward with florian's proposal to make spec more permissive
<TabAtkins> TabAtkins: ian was objecting to that, he prefers edge's behavior
<TabAtkins> iank_: my strong pref and i think koji's is edge's beahvior
<TabAtkins> florian: have we looked at what other good typography stuff has done? we're not inventing the subject
<TabAtkins> jfkthame: usual answer in typo is you don't do underlining
<TabAtkins> astearns: or you're very explicit about the effect you want
<TabAtkins> astearns: indesign allows you to do whatever you want with the line tool
<florian> s/stuff/software/
<TabAtkins> astearns: so we're talkign about autoamted tools
<ChrisLilley> *use inline svg*
<TabAtkins> TabAtkins: but latex is automated too
<TabAtkins> fremy: for latex, subs don't get an underline, and people are asking about how to get it to work
<TabAtkins> fremy: so as far as i can see it just doesn't draw and that's bad
<TabAtkins> fantasai: i'd expect that you draw the underline at correct position and skip subs, or use a lower underline position
<TabAtkins> fantasai: just as a document style
<TabAtkins> florian: alan, you said indesign will do whatever, but it does it provide a way out of the box to do like edge, or do you have to do it manually?
<TabAtkins> astearns: i'd ahve to check
<TabAtkins> fantasai: don't think i've ever seen edge's behaior in a document taht wasn't generated by a browser
<jfkthame> fantasai++
<TabAtkins> fremy: i'd assume Word does that
<florian> s/will do/will let you do/
<TabAtkins> Rossen_: that's correct
<Rossen_> q?
<TabAtkins> Rossen_: so we have a spec that describes firefox behavior
<TabAtkins> Rossen_: we have a strong desire from blink to ipmlemenht the Word/Edge behavior
<TabAtkins> Rossen_: if we need to allow both, we need at least a MAY
<fremy> FWIW, Word does indeed behave like EdgeHTML
<TabAtkins> Rossen_: so that doesn't give us much specification
<TabAtkins> TabAtkins: it would still help with supers to make sure that's clear
<TabAtkins> florian: right, still an improvement over chrome's old behavior
<ChrisLilley> fremy probably both usind DirectWrite api
<futhark> present-
<fremy> ChrisLilley: quite likely, indeed
<TabAtkins> fantasai: think i don't really want to increase variations that typographers would be unhappy abot
<TabAtkins> fantasai: so don't want to adopt edge's behavior unless there's typography community people wanting it
<TabAtkins> iank_: do we ahve evidence that people dont' want it? that' surprising to me, sicne it's in Word
<TabAtkins> jfkthame: Word isn't generally considered the epitome of typography
<TabAtkins> jfkthame: just tested Pages on Mac, if you have a sub it moves the entire line's underline
<TabAtkins> iank_: per line or per paragraph?
<TabAtkins> jfkthame: didn't go that far
<TabAtkins> iank_: would it help to quickly show examples?
<TabAtkins> iank_: [old chrome behavior, baseline jumps all over for subs and supers. consistent per individual element]
<TabAtkins> iank_: [firefox's behavior, underline is just dominant. ink-skipping can make it appear to not draw for subs, depending on how the glyph is]
<TabAtkins> iank_: [dominant baseline *per element*, so lines without a sub/super still have the underline shifted]
<dholbert> FWIW, LibreOffice seems to match the EdgeHTML behavior (not that LibreOffice is necessarily the pinnacle of text layout; just as another-agreeing-implementation)
<TabAtkins> florian: I checked apple pages, it shifts per line, not per paragraph
<emeyer> q+
<TabAtkins> iank_: [Edge's behavior - underline is dominant, but subs break it and draw their own underline fragment to their dominant baseline. supers don't affect the underline]
<TabAtkins> fantasai: I think firefox's behavior is closest to what i'd expect form good typog
<emeyer> q-
<fantasai> emeyer: I agree
<TabAtkins> florian: firefox beahvior could be made smarter
<dbaron> s/typog/typography/
<dbaron> s/form/from/
<TabAtkins> fantasai: and i'd expect ink-skipping with a consisten tposition to look best
<TabAtkins> fantasai: if your'e not skipping, that's obvious a little bad
<bramus> (Sidenote for macOS users: System Preferences > Accessibility > Zoom: hit checkbox “Use scroll gesture …” and then you can zoom in by scrolling while holding a modifier key. Don’t know if that plays nice with screen sharing though)
<TabAtkins> fantasai: if you have a lot of subs and supers mixed together, you should probabyl generally choose a lower underlie position
<TabAtkins> fantasai: I don't think I'd expect Edge's behavior from a well-typeset doc
<TabAtkins> iank_: is it permissible to skip a giant sub?
<TabAtkins> fantasai: default is ink skipping
<TabAtkins> iank_: I mean skip entirely, not just ink-skip
<ChrisLilley> s/en tpos/ent pos/
<TabAtkins> iank_: ink skipping works for shorter cases, like this small B sub
<TabAtkins> iank_: but the big edge case is a long subscript
<TabAtkins> fantasai: we should be optimizing for reasonable cases
<TabAtkins> several: nah we've seen long subs
<Rossen_> q?
<TabAtkins> fantasai: i think standard will be short subscripts and we should optimize for that
<ChrisLilley> ironic typography
<TabAtkins> fantasai: there has been requests to turn off underline for an element, that's an open Text 4 request
<TabAtkins> fantasai: so if someone wanted to skip, that should be posible to spec
<TabAtkins> una: i noticed if you have a sub that's a link, that's common, it'll have a double underline - parent going thru it, then its underline
<TabAtkins> fantasai: yeah edge behavior gives you multiple, but spec behavior is to have one single line that doesn't move
<bkardell_> I was saying that I agree it is unusual for a long run of text as a subscript in general, but a lot of times superscripts are links, which generally are underlined
<TabAtkins> fantasai: so per spec you wouldn't have double underline
<TabAtkins> Rossen_: [shows Word with a bunch of different font-size subs, generating multiple staggered underlines]
<TabAtkins> Rossen_: this example where you break the first line for a subscript out of the larger set font
<fantasai> [changing the baseline position breaks the underline averaging segments in Word]
<TabAtkins> florian: I think this is different and more complex than what was described as edge behavior
<TabAtkins> florian: you're saying we ahve one continuous underline until we hit the sub, then it changes after th esub?
<TabAtkins> fantasai: that's because word doesn't have a nesting hierarchy, it's just a linear stream of elements. so it can't preserve across a sub break
<astearns> InDesign also does not have a hierarchy of elements. So I don’t think we should follow InDesign OR Word
<TabAtkins> florian: I think LibreOffice does the edge behavior but people are asking how to not do that on SE
<fantasai> s/preserve/preserve formatting/
<TabAtkins> fremy: I cared strongly when this was first filed because we didn't have agreement, but less now
<TabAtkins> fremy: I think Edge's behavior is safe, but if we think it's reasonable to cross the text and rely on ink skipping, i think it's an option. i don't think it's best but i'd be okay with it
<fantasai> s/agreement/ink skipping/
<TabAtkins> iank_: I want to talk with koji to see what he'd think about, not just ink skipping but totally skipping the sub; would be identical in common cases but different in the degenerate long-text case
<TabAtkins> fremy: only downside is it's entirely accidental if the whole text is subbed
<TabAtkins> fantasai: agree it shouldn't be defualt, author should opt in maybe
<TabAtkins> iank_: i'd agree
<TabAtkins> iank_: ink skipping doesn't necessarily get a good effect, it still looks like text is crossed out
<Rossen_> q?
<TabAtkins> Rossen_: so it sounds like firefox's behavior is still something we want to keep
<TabAtkins> Rossen_: strong desire from ian and team to experiement and see if they can get something closer to Edge behavior
<TabAtkins> Rossen_: q is how do we allow it
<emeyer> q+
<TabAtkins> fantasai: i don't think this is good to adtop unless people other than browser eng want it
<TabAtkins> fremy: Well Word is doing it and people use it every day
<TabAtkins> florian: I just went to Word support forum and answer for if you want to do another behavior is "use more advanced typesetting software"
<florian> https://answers.microsoft.com/en-us/msoffice/forum/all/underline-subscript-is-uneven/786e1222-87c4-4dc9-97de-83b3a08a32d8
<TabAtkins> fantasai: I want somebody specializing in good typog to say "Word behavior is good and waht we want"
<TabAtkins> fremy: yeah but usual policy is to say eve if layout is weird, text should be readable
<TabAtkins> fantasai: we try to make sure behavior is good by defualt, and resilient in weird. doesn't mean we choose bad beahvior because it's th emost straightforward way to be resilient
<Rossen_> ack emeyer
<TabAtkins> emeyer: from what i remember of edge and firefox cases, i do not see why we'd pick Edge over Firefox
<TabAtkins> emeyer: what firefox was doing for ink skipping and various cases seemed like a better approach on balance
<astearns> I dislike Edge’s behavior because it does two different things depending on whether a line starts with a span shifted up or shifted down relative to the rest of th eline
<TabAtkins> emeyer: i'm not a typog expert, but i spent a lot of time looking at text
<TabAtkins> emeyer: I'd be comfortable asking the wider community
<TabAtkins> emeyer: I agree with elika, we're trying to make typog better, let's actually make it better
<una> q?
<TabAtkins> una: do we want to do a survey?
<TabAtkins> una: my team can organize it
<TabAtkins> emeyer: would support it
<TabAtkins> Rossen_: would be helpful
<TabAtkins> ChrisLilley: should be clear it's "what do you want to see" not just "what does your software do"
<TabAtkins> fantasai: "what do you like better: picture, picture, picture"
<TabAtkins> florian: Also with short sub we seem to agree firefox is good, only for long do we disagree
<TabAtkins> florian: Isn't it pref to use the spec allowance to move the entire line down?
<TabAtkins> iank_: I think there's three options here
<TabAtkins> iank_: First is firefox's, for short subs ink-skipping makes it readable
<TabAtkins> iank_: Second is Edge, where subs move the line down
<TabAtkins> iank_: Third is don't draw the underline on subs at all
<fantasai> Fourth is move the line down
<TabAtkins> iank_: This has similar practical behavior ot Firefox's for short; for long it will be different
<Rossen_> For the record - neither of the answers posted by florian's link above are official Microsoft answers but folks from the community
<TabAtkins> florian: Think there's four - largely do firefox, but allow for shifting the whole run's underline, perhaps with a guard to ony do it when it's long
<TabAtkins> fantasai: don't think it's great, it's unpredictable then
<TabAtkins> fantasai: if you have five subs, two on a line skip but three shift, that's weird
<TabAtkins> fantasai: should pick one behavior, author can get other behaviors
<TabAtkins> Rossen_: we can decid enot to change
<TabAtkins> florian: i said my fourth was possibly conditional. if it's not conditional, it matches apple
<florian> s/apple/Apple Pages/
<TabAtkins> Rossen_: so we can't get resolution yet.
<TabAtkins> Rossen_: We want to do a survey that catches all the cases we just described, carefully not conditioning people to one tech or another
<TabAtkins> fantasai: I suggest me and Una work on this
<TabAtkins> Rossen_: And I think convo captures enough info for posterity
<fantasai> ACTION: fantasai and Una to make a survey about underlining subscripts
<TabAtkins> Rossen_: and strong desires of what we believe is good
<TabAtkins> Rossen_: anything else before we end?
<Rossen_> q?
<TabAtkins> Rossen_: so let's close the issue
<TabAtkins> <br dur=1hr>