| Summary: | Underlines and strikethrough geometry could be refined/improved | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | WebKit | Reporter: | Ryan Bugden <hi> | ||||||||
| Component: | Text | Assignee: | Nobody <webkit-unassigned> | ||||||||
| Status: | REOPENED --- | ||||||||||
| Severity: | Normal | CC: | mmaxfield, webkit-bug-importer | ||||||||
| Priority: | P2 | Keywords: | InRadar | ||||||||
| Version: | Safari 16 | ||||||||||
| Hardware: | All | ||||||||||
| OS: | All | ||||||||||
| URL: | https://hex.xyz/misc/text-decoration-test/ | ||||||||||
| Attachments: |
|
||||||||||
|
Description
Ryan Bugden
2023-07-04 10:06:16 PDT
(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. Created attachment 466921 [details]
zoomed in
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. (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.) Created attachment 466925 [details]
Current strikethrough behavior on Firefox
Reopening to refine placement of strike-throughs and underlines. Hi there! I'm curious to get an update on this issue. Any progress or thoughts? Thanks! |