Bug - [Patternfly Table] - [HiDPI (Retina Mac) rendering issue]

[gruselhaus]

Describe the problem
The row dividers of the patternfly table component is rendered incorrectly on Apple Retina Displays in Safari. This issue affects probably all HiDPI screens but I could only test it on a Mac.

How do you reproduce the problem?
Due to the fact that this problem affects all pages with Patternfly Table, this error also appears in the official demos of Patternfly.
Just open this official patternfly demo on a Retina Mac in Safari => https://codesandbox.io/s/kkk1gd

Expected behavior
The dividers should be rendered uniformly and cleanly.

Screenshots

[mcoker]

Also visible in the basic examples - https://www.patternfly.org/v4/components/table/html

[mcoker]

@mattnolting would you mind having a look at this?

[mattnolting]

@gruselhaus @mcoker This is a known webkit bug https://bugs.webkit.org/show_bug.cgi?id=243167. Looks like safari is miscalculating td height and drawing a duplicate border (even when there is no border applied) for text-based alignment text-top, text-bottom, baseline, etc.

[stale]

This issue has been automatically marked as stale because it has not had activity in the last 60 days. It will be closed in 30 days if no further activity occurs.

[jiridostal]

This is still valid and furthermore was observed in Chrome too. Is there any plan on fixing this? I would appreciate more references on why this happens

[jelly]

We've also encountered this in Cockpit-podman cockpit-project/cockpit-podman#1485 with some findings from @garrett here.

[garrett]

We've seen this on when zoomed in on WebKit browsers, after reloading the page, when text-align is set to baseline and you have mixed elements (text and other things, like buttons). This becomes even more of a problem the more you zoom the page too.

We've seen the issue on standard DPI Linux with GNOME Web too, but only when zoomed. I'm guessing HiDPI is probably similar on Linux, but haven't tested it yet.

Details @ cockpit-project/cockpit-podman#1485

If you change the alignment to something other than baseline, it's fine.

One possible workaround might be to declare a text-baseline a second time (keeping the initial one for all other browsers) and use vertical-align: -webkit-baseline-middle. We'd need to check that it has the desired effect, of course, as this affects both WebKit and Blink (Gecko has -moz-middle-with-baseline). They might be similar enough to baseline but not trigger this bug. It'd require some testing.

Or we could change it to something else, like vertical-align: top... but that would likely have other alignment issues on all browsers when you mix text and other widgets (buttons, kebab menus, etc.). Or possibly vertical-align: middle, but then you'd have issues with 1-line-high text and lines of text that wrap, along with other differently sized text.

The alignment is not a problem with everything set at the same height (all 1-line-high text, for example); it becomes a problem for this bug (and any workarounds) when you have elements with different heights.