[Webkit-unassigned] [Bug 258857] Underline/strikethrough thickness/position (from-font) don't reflect font metadata

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=258857

--- Comment #4 from Ryan Bugden <hi at ryanbugden.com> ---
(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.)

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20230704/d1bccdc0/attachment.htm>