Bug 195968
| Summary: | border collapsing: subpixels can make table-cell with smaller border width "win" over table with larger width | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | David Grogan <dgrogan> |
| Component: | Layout and Rendering | Assignee: | Nobody <webkit-unassigned> |
| Status: | NEW | ||
| Severity: | Normal | CC: | ahmad.saleem792, bfulgham, simon.fraser, webkit-bug-importer, zalan |
| Priority: | P2 | Keywords: | FromImplementor, InRadar |
| Version: | Safari Technology Preview | ||
| Hardware: | Unspecified | ||
| OS: | macOS 10.13 | ||
David Grogan
http://w3c-test.org/css/css-tables/subpixel-collapsed-borders-003.html passes in hi-dpi but fails in low-dpi. Its essence is:
<table style="border-collapse: collapsed; border-width:5.95px">
<td style="border-width:5px"></td>
</table>
In the collapsed border resolution algorithm, Safari (and Firefox) presumably use border widths after they've been rounded to device pixels. In the test above, the table's 5.95px border should beat the cell's 5px border.
But rounding causes 5.95px to round down to 5px on a 1x ratio device. So the table and cell have the same widths. When the widths are the same, the cell beats the table. On a 2x device, 5.95px is rounded to 5.5px, making the table beat the cell.
The pre-rounded width should be used in the algorithm so that colors don't change based on the user's device pixel ratio.
(I filed an identical Firefox bug at https://bugzilla.mozilla.org/show_bug.cgi?id=1536646)
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
Radar WebKit Bug Importer
<rdar://problem/49137686>
Ahmad Saleem
This testcase is on WPT and we are passing it on STP168 - https://wpt.fyi/results/css/css-tables/subpixel-collapsed-borders-003.html?label=experimental&label=master&aligned
@Alan - this is about low-dpi, do we need to track it with more granular reproduced test case or anything else?
alan
.95 is normally ceiled to 1 on both 1x and 2x screens. Maybe there's something more to this.