Bug 258857 – Underlines and strikethrough geometry could be refined/improved

• Component: Text
• Status: REOPENED

[Ryan Bugden]

Created attachment 466919 [details]
A screenshot of a key part our test page, showing the behavior or underline and strikethrough in Webkit/Safari.

Problem:
The treatment of underlines and strikethroughs is off.

Steps to reproduce the problem:
1. Open up our test webpage in Webkit/Safari: https://hex.xyz/misc/text-decoration-test/
2. Please read everything in Webkit/Safari, and observe.

With `from-font`:
In using `text-decoration-thickness: from-font` and `text-underline-position: from-font`, the results do not accurately reflect the metadata in the font.
- The position of the strikethrough is not correct (also, there is currently no CSS tag for this: https://github.com/w3c/csswg-drafts/issues/9027).
- The thickness and position of the underline is slightly off, but acceptable.

Without `from-font`:
The underline/strikethrough thickness/position seems arbitrary and won’t necessarily work for every font. 

Here is our suggested fix:
- Improve how text-decoration with a `from-font` value is rendered.
- Make getting the data `from-font` the default behavior for underline/strikethrough position/thickness. Typeface designers and font engineers put a lot of thought into these values, and they know their fonts best, so these should be the first resort.
- In lieu of a CSS tag for `text-strikethrough-position`, like underline thickness/position and strikethrough thickness, strikethrough position should be determined by first looking for the value in the font’s metadata.

As far as technical implementation, WebKit, when rendering the strikethrough of a font, should reference the value in the `yStrikeoutPosition` key from the OS2 table, and interpret that value as the top y-coordinate of the line. See below:
https://learn.microsoft.com/en-us/typography/opentype/spec/os2

Thank you for your consideration!

[Myles C. Maxfield]

(In reply to Ryan Bugden from comment #0)
> With `from-font`:
> In using `text-decoration-thickness: from-font` and
> `text-underline-position: from-font`, the results do not accurately reflect
> the metadata in the font.
> - The position of the strikethrough is not correct (also, there is currently
> no CSS tag for this: https://github.com/w3c/csswg-drafts/issues/9027).

Right, there's nothing WebKit can really do about this until the CSSWG creates a mechanism for the author to indicate they want the strikethrough info to come from the font. I suggest filing an issue at https://github.com/w3c/csswg-drafts/issues/new for the CSS Working Group.

> - The thickness and position of the underline is slightly off, but
> acceptable.

WebKit intentionally rounds the position and size of underlines to device pixel boundaries. We do this because it makes underlines look crisp (which we think makes them look better, especially at small font sizes). I'm attaching a screenshot showing the content zoomed-in - you can see the difference is that we are rounding the underline but the black line isn't.

> 
> Without `from-font`:
> The underline/strikethrough thickness/position seems arbitrary and won’t
> necessarily work for every font. 

I wrote a patch years ago to enable `font-font` by default for all text, but too many fonts have bogus values in them. Too much content broke. I had to revert the patch the next day.

[Myles C. Maxfield]

Created attachment 466921 [details]
zoomed in

[Myles C. Maxfield]

So, I think there's nothing to do here, at least until the CSS creates a mechanism for the author to indicate they want the geometry of the strikethrough to come from the font.

[Ryan Bugden]

(In reply to Myles C. Maxfield from comment #3)
Hi Max, thanks so much for your reply and consideration.

> WebKit intentionally rounds the position and size of underlines to device pixel boundaries.
Ah, good to know. Understood here, and agree with how you're thinking about it.

> there's nothing WebKit can really do about this until the CSSWG creates a mechanism for the author to indicate they want the strikethrough info to come from the font.
I've filed an issue here: https://github.com/w3c/csswg-drafts/issues/9027. In the meantime, do you think it would be a prudent approach to default to honoring the font’s strikethrough position? FWIW (forgive the comparison) Firefox—although their underline treatment is currently off—seems to do this piece by default already without any CSS intervention (attachment inbound).

> too many fonts have bogus values in them
I hear you on this. There is also the possibility of a heuristic approach. What do you think about the following?

- If strikethrough position is above cap-height or below baseline, kick into whatever WebKit’s default is. Otherwise honor the font’s metadata.
- If underline position is below (descender value * 3) (just an idea), kick into whatever WebKit’s default is. Otherwise honor the font’s metadata.
(In other words, heed font metadata unless found to be bogus.)

My general thought is that it would be great if the values that type designers take time to put into their fonts is honored more often on the web (IME, most devs aren't thinking about, or aware of, `from-font` on the first go-round.)

[Ryan Bugden]

Created attachment 466925 [details]
Current strikethrough behavior on Firefox

[Myles C. Maxfield]

Reopening to refine placement of strike-throughs and underlines.

[Radar WebKit Bug Importer]

<rdar://problem/112086722>

[Ryan Bugden]

Hi there! I'm curious to get an update on this issue. Any progress or thoughts? Thanks!