201725 2019-09-12 10:03:28 -0700 maisonalyzee.com: Text incorrectly wrapped 2026-09-24 02:29:35 -0700 1 1 1 Unclassified WebKit Text WebKit Nightly Build Unspecified Unspecified RESOLVED FIXED https://bugs.webkit.org/show_bug.cgi?id=261212 https://github.com/web-platform-tests/wpt/pull/62808 https://www.maisonalyzee.com/ BrowserCompat, InRadar P2 Normal --- 324291 324355 1 youennf bfulgham ahmad.saleem792 ap bfulgham jfkthame jonlee mmaxfield simon.fraser webkit-bug-importer zalan oldest_to_newest 1570287 0 youennf 2019-09-12 10:03:28 -0700 The 'e' of ALYZÉE is misplaced and the menu is not 100% visible. Chrome renders it ok. Safari does not. Firefox does not. 1570288 1 youennf 2019-09-12 10:04:11 -0700 Given Firefox has the same behaviour, I wonder whether the website is not browser specific. 1570295 2 simon.fraser 2019-09-12 10:28:06 -0700 It's certainly better in FF and Chrome. WebKit seems to have some z-ordering issues. 1570296 3 webkit-bug-importer 2019-09-12 10:28:21 -0700 <rdar://problem/55307109> 1570448 4 ap 2019-09-12 17:42:23 -0700 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. 1925557 5 ahmad.saleem792 2023-01-14 06:19:34 -0800 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! 1925576 6 464500 zalan 2023-01-14 08:44:52 -0800 Created attachment 464500 Test reduction 1925585 7 zalan 2023-01-14 10:24:25 -0800 The container width is set to 529px. We measure the content 529.73px wide -> fractional overflow. 2249691 8 bfulgham 2026-09-11 16:08:06 -0700 Pull request: https://github.com/WebKit/WebKit/pull/73813 2250826 9 ews-feeder 2026-09-15 16:12:32 -0700 Committed 321206@main (f62c19686abf): <https://commits.webkit.org/321206@main> Reviewed commits have been landed. Closing PR #73813 and removing active labels. 2250842 10 bfulgham 2026-09-15 16:53:54 -0700 Re-opening for pull request https://github.com/WebKit/WebKit/pull/74100 2250843 11 bfulgham 2026-09-15 16:56:00 -0700 Ignore that last comment. We are tracking this under its own radar. 2251091 12 bfulgham 2026-09-16 09:20:23 -0700 Follow-up (clean-up for dead code) in Bug 324291. 2252052 13 bfulgham 2026-09-18 17:16:16 -0700 Submitted web-platform-tests pull request: https://github.com/web-platform-tests/wpt/pull/62808 2254027 14 jfkthame 2026-09-24 02:29:35 -0700 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. 464500 2023-01-14 08:44:52 -0800 2023-01-14 08:44:52 -0800 Test reduction shrink-cake.html text/html 492 zalan PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJz ZXQ9VVRGLTgiPgoKPHN0eWxlPgpAZm9udC1mYWNlIHsKICBmb250LWZhbWlseTogd2ZfMTVkNjEw MDJjZjUxNDc2Mjk0ZjI3MzUzMTsKICBzcmM6IHVybCgiaHR0cHM6Ly9zdGF0aWMud2l4c3RhdGlj LmNvbS91Zm9udHMvN2E3NGRiXzE1ZDYxMDAyY2Y1MTQ3NjI5NGYyNzM1MzFhMGNlZjFkL3dvZmYy L2ZpbGUud29mZjIiKSBmb3JtYXQoIndvZmYyIikKfQoKZGl2IHsKICBib3JkZXI6IHNvbGlkOwog IHdpZHRoOiA1MjlweDsKICBmb250LWZhbWlseTogd2ZfMTVkNjEwMDJjZjUxNDc2Mjk0ZjI3MzUz MTsKICBmb250LXNpemU6IDQ1cHg7CiAgZm9udC13ZWlnaHQ6Ym9sZDsKfQo8L3N0eWxlPgo8IS0t IFBBU1MgaWYgY29udGVudCBmaXRzIGluIG9uZSBsaW5lIC0tPgo8ZGl2PiZuYnNwOyBNIGEgaSBz IG8gbiZuYnNwOyAmbmJzcDtBIGwgeSB6IMOpIGU8L2Rpdj4K