Created attachment 461197 [details] Examples of correct and buggy behavior I checked this bug against Safari 15 *and* the latest Tech Preview. When you have a table that has cells that: 1. Use a text-based `vertical-align` (`text-top`, `baseline`, etc…); and 2. Contain one or more block-level elements; and 3. Have collapsed borders; and 4. Those borders are 1px wide An extra bottom border is rendered just below the bounding box of the text _in addition to_ the expected border where the rows meet. This does cause the text to shift upwards. This extra border is drawn only for the cells that DO NOT have the additional element inside. This behavior happens even when the added element is `position: fixed` or `position: absolute`. Additionally, the initial alignment box for the text is calculated incorrectly if a table initially uses `border-collapse: collapse` versus toggling that property separately via JS. I've provided an example with a handful of small notes and examples of what's happening.
<rdar://problem/97914178>
We're seeing this issue in Cockpit, and it's triggered in all other PatternFly apps using tables as well. It affects WebKit in both Safari and GNOME Web, and becomes much worse when text is zoomed in (especially reloading or revisiting a page after zooming) or when using a browser HiDPI (both in macOS and Linux). PatternFly bug (with screenshots): https://github.com/patternfly/patternfly/issues/5016 Cockpit issue (with screenshots that further illustrate the issue): https://github.com/cockpit-project/cockpit-podman/issues/1485 You can see it in action @ https://www.patternfly.org/components/table/#actions — be sure to zoom (ctrl+) and reload the page or use HiDPI to see the problem more clearly.