RESOLVED FIXED201725
maisonalyzee.com: Text incorrectly wrapped 
https://bugs.webkit.org/show_bug.cgi?id=201725
Summary maisonalyzee.com: Text incorrectly wrapped
youenn fablet
Reported 2019-09-12 10:03:28 PDT
The 'e' of ALYZÉE is misplaced and the menu is not 100% visible. Chrome renders it ok. Safari does not. Firefox does not.
Attachments
Test reduction (492 bytes, text/html)
2023-01-14 08:44 PST, alan 		no flags
Details
View All Add attachment proposed patch, testcase, etc.
youenn fablet
Comment 1 2019-09-12 10:04:11 PDT
Given Firefox has the same behaviour, I wonder whether the website is not browser specific.
Simon Fraser (smfr)
Comment 2 2019-09-12 10:28:06 PDT
It's certainly better in FF and Chrome. WebKit seems to have some z-ordering issues.
Radar WebKit Bug Importer
Comment 3 2019-09-12 10:28:21 PDT
<rdar://problem/55307109>
Alexey Proskuryakov
Comment 4 2019-09-12 17:42:23 PDT
Looks like a different font style ends up being used by Safari and Firefox vs. Chrome, so our text is wider. z-ordering seems like it should be tracked as a separate bug, as this is not part of the original description, and certainly has a separate cause.
Ahmad Saleem
Comment 5 2023-01-14 06:19:34 PST
Still reproducing: Safari 16.2 - E is misplaced Safari Technology Preview - E is misplaced Chrome Canary 111 - working fine Firefox Nightly 110 - working fine Just wanted to share updated test results. Thanks!
alan
Comment 6 2023-01-14 08:44:52 PST
Created attachment 464500 [details] Test reduction
alan
Comment 7 2023-01-14 10:24:25 PST
The container width is set to 529px. We measure the content 529.73px wide -> fractional overflow.
Brent Fulgham
Comment 8 2026-09-11 16:08:06 PDT
Pull request: https://github.com/WebKit/WebKit/pull/73813
EWS
Comment 9 2026-09-15 16:12:32 PDT
Committed 321206@main (f62c19686abf): <https://commits.webkit.org/321206@main> Reviewed commits have been landed. Closing PR #73813 and removing active labels.
Brent Fulgham
Comment 10 2026-09-15 16:53:54 PDT
Re-opening for pull request https://github.com/WebKit/WebKit/pull/74100
Brent Fulgham
Comment 11 2026-09-15 16:56:00 PDT
Ignore that last comment. We are tracking this under its own radar.
Brent Fulgham
Comment 12 2026-09-16 09:20:23 PDT
Follow-up (clean-up for dead code) in Bug 324291.
Brent Fulgham
Comment 13 2026-09-18 17:16:16 PDT
Submitted web-platform-tests pull request: https://github.com/web-platform-tests/wpt/pull/62808
Jonathan Kew
Comment 14 2026-09-24 02:29:35 PDT
I don't think there is any basis in the CSS Fonts spec for requiring synthetic-bold to have the same glyph advance metrics as the regular face. In most font families, bold tends to have larger advances than regular, and it's entirely reasonable for a browser that is synthesizing bold in the absence of a real face to do the same thing. So IMO the web-platform-tests added here are imposing a constraint that the spec does not mandate, and that conflicts with common typographic expectations.
Note You need to log in before you can comment on or make changes to this bug.