[css-backgrounds] Border width rounding affects collapsed border conflict resolution #7473

wangxianzhu · 2022-07-07T19:41:15Z

<table style="border-collapse: collapse">
  <tr><td style="border: 5.1px solid blue">BLUE</td></tr>
  <tr><td style="border: 5.9px solid red">RED</td></tr>
</table>

On Firefox (and perhaps WebKit, and perhaps future Blink), the color of the border between the two table cells depends on the device scale factor. When dsf=1, it's blue. When dsf=2, it's red.

This issue depends on #5210.

The text was updated successfully, but these errors were encountered:

Chrome renders a 1 pixel gap between a parent's border and a child's background, when a sub pixel borders widths decimal value is greater than or equal to 0.5. This happens because * the parent's size gets calculated at layout time with the sub pixel values * the child's position gets calculated based on the parent's position and size * the border width gets floored at paint time to just the whole value This leaves a 1 pixel gap between the last pixel in the parent's border and the first pixel in the child's background. This behavior is a regression introduced in: https://chromium-review.googlesource.com/c/chromium/src/+/2199140 Which changed Chrome to "Use floor instead of round for decimal border widths" with the intent to increase interop with Firefox and Safari which both floor borders. Previously Chrome was rounding the borders at Paint time, avoiding the gaps between a parent's border and a child's background. The proposed fix is to snap (floor) the borders widths before layout, matching what Gecko and WebKit do. Outline widths also use `ConvertBorderWidth` as their conversion function and will also be snapped before layout. CSS isses: w3c/csswg-drafts#5210 w3c/csswg-drafts#7473 R=pdr Change-Id: Ib32ba28e4f193ba79f90f96771378abaf0c589a8 Bug: 1120347, 1201762

Chrome renders a 1 pixel gap between a parent's border and a child's background, when a sub pixel borders widths decimal value is greater than or equal to 0.5. This happens because * the parent's size gets calculated at layout time with the sub pixel values * the child's position gets calculated based on the parent's position and size * the border width gets floored at paint time to just the whole value This leaves a 1 pixel gap between the last pixel in the parent's border and the first pixel in the child's background. This behavior is a regression introduced in: https://chromium-review.googlesource.com/c/chromium/src/+/2199140 This CL is also reverting the subpixel border width behavior of https://codereview.chromium.org/2640143005 Which changed Chrome to "Use floor instead of round for decimal border widths" with the intent to increase interop with Firefox and Safari which both floor borders. Previously Chrome was rounding the borders at Paint time, avoiding the gaps between a parent's border and a child's background. The proposed fix is to snap (floor) the borders widths before layout, matching what Gecko and WebKit do. Outline widths also use `ConvertBorderWidth` as their conversion function and will also be snapped before layout. While Column-Rule widths were already snapped before layout by `StyleBuilderConverter::ConvertLineWidth`, with this CL they will also use `StyleBuilderConverter::ConvertBorderWidth` in order to unify the snapping of widths behavior and code paths. CSS isses: w3c/csswg-drafts#5210 w3c/csswg-drafts#7473 R=pdr Change-Id: Ib32ba28e4f193ba79f90f96771378abaf0c589a8 Bug: 1120347, 1201762

Chrome renders a 1 pixel gap between a parent's border and a child's background, when a sub pixel borders widths decimal value is greater than or equal to 0.5. This happens because * the parent's size gets calculated at layout time with the sub pixel values * the child's position gets calculated based on the parent's position and size * the border width gets floored at paint time to just the whole value This leaves a 1 pixel gap between the last pixel in the parent's border and the first pixel in the child's background. This behavior is a regression introduced in: https://chromium-review.googlesource.com/c/chromium/src/+/2199140 This CL is also reverting the subpixel border width behavior of https://codereview.chromium.org/2640143005 Which changed Chrome to "Use floor instead of round for decimal border widths" with the intent to increase interop with Firefox and Safari which both floor borders. Previously Chrome was rounding the borders at Paint time, avoiding the gaps between a parent's border and a child's background. The proposed fix is to snap (floor) the borders widths before layout, matching what Gecko and WebKit do. Outline widths also use `ConvertBorderWidth` as their conversion function and will also be snapped before layout. While Column-Rule widths were already snapped before layout by `StyleBuilderConverter::ConvertLineWidth`, with this CL they will also use `StyleBuilderConverter::ConvertBorderWidth` in order to unify the snapping of widths behavior and code paths. CSS isses: w3c/csswg-drafts#5210 w3c/csswg-drafts#7473 R=pdr Change-Id: Ib32ba28e4f193ba79f90f96771378abaf0c589a8 Bug: 1120347, 1201762 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3717365 Reviewed-by: David Baron <dbaron@chromium.org> Reviewed-by: Philip Rogers <pdr@chromium.org> Commit-Queue: Traian Captan <tcaptan@chromium.org> Reviewed-by: Xianzhu Wang <wangxianzhu@chromium.org> Owners-Override: Philip Rogers <pdr@chromium.org> Cr-Commit-Position: refs/heads/main@{#1060652}

…dths before Layout, a=testonly Automatic update from web-platform-tests Snap Border, Outline, and Column-Rule Widths before Layout Chrome renders a 1 pixel gap between a parent's border and a child's background, when a sub pixel borders widths decimal value is greater than or equal to 0.5. This happens because * the parent's size gets calculated at layout time with the sub pixel values * the child's position gets calculated based on the parent's position and size * the border width gets floored at paint time to just the whole value This leaves a 1 pixel gap between the last pixel in the parent's border and the first pixel in the child's background. This behavior is a regression introduced in: https://chromium-review.googlesource.com/c/chromium/src/+/2199140 This CL is also reverting the subpixel border width behavior of https://codereview.chromium.org/2640143005 Which changed Chrome to "Use floor instead of round for decimal border widths" with the intent to increase interop with Firefox and Safari which both floor borders. Previously Chrome was rounding the borders at Paint time, avoiding the gaps between a parent's border and a child's background. The proposed fix is to snap (floor) the borders widths before layout, matching what Gecko and WebKit do. Outline widths also use `ConvertBorderWidth` as their conversion function and will also be snapped before layout. While Column-Rule widths were already snapped before layout by `StyleBuilderConverter::ConvertLineWidth`, with this CL they will also use `StyleBuilderConverter::ConvertBorderWidth` in order to unify the snapping of widths behavior and code paths. CSS isses: w3c/csswg-drafts#5210 w3c/csswg-drafts#7473 R=pdr Change-Id: Ib32ba28e4f193ba79f90f96771378abaf0c589a8 Bug: 1120347, 1201762 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3717365 Reviewed-by: David Baron <dbaron@chromium.org> Reviewed-by: Philip Rogers <pdr@chromium.org> Commit-Queue: Traian Captan <tcaptan@chromium.org> Reviewed-by: Xianzhu Wang <wangxianzhu@chromium.org> Owners-Override: Philip Rogers <pdr@chromium.org> Cr-Commit-Position: refs/heads/main@{#1060652} -- wpt-commits: 250c39d10718c061fa6640eeb6d64b66e0968681 wpt-pr: 36189

…dths before Layout, a=testonly Automatic update from web-platform-tests Snap Border, Outline, and Column-Rule Widths before Layout Chrome renders a 1 pixel gap between a parent's border and a child's background, when a sub pixel borders widths decimal value is greater than or equal to 0.5. This happens because * the parent's size gets calculated at layout time with the sub pixel values * the child's position gets calculated based on the parent's position and size * the border width gets floored at paint time to just the whole value This leaves a 1 pixel gap between the last pixel in the parent's border and the first pixel in the child's background. This behavior is a regression introduced in: https://chromium-review.googlesource.com/c/chromium/src/+/2199140 This CL is also reverting the subpixel border width behavior of https://codereview.chromium.org/2640143005 Which changed Chrome to "Use floor instead of round for decimal border widths" with the intent to increase interop with Firefox and Safari which both floor borders. Previously Chrome was rounding the borders at Paint time, avoiding the gaps between a parent's border and a child's background. The proposed fix is to snap (floor) the borders widths before layout, matching what Gecko and WebKit do. Outline widths also use `ConvertBorderWidth` as their conversion function and will also be snapped before layout. While Column-Rule widths were already snapped before layout by `StyleBuilderConverter::ConvertLineWidth`, with this CL they will also use `StyleBuilderConverter::ConvertBorderWidth` in order to unify the snapping of widths behavior and code paths. CSS isses: w3c/csswg-drafts#5210 w3c/csswg-drafts#7473 R=pdr Change-Id: Ib32ba28e4f193ba79f90f96771378abaf0c589a8 Bug: 1120347, 1201762 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3717365 Reviewed-by: David Baron <dbaron@chromium.org> Reviewed-by: Philip Rogers <pdr@chromium.org> Commit-Queue: Traian Captan <tcaptan@chromium.org> Reviewed-by: Xianzhu Wang <wangxianzhu@chromium.org> Owners-Override: Philip Rogers <pdr@chromium.org> Cr-Commit-Position: refs/heads/main@{#1060652} -- wpt-commits: 250c39d10718c061fa6640eeb6d64b66e0968681 wpt-pr: 36189

tabatkins · 2023-02-27T21:05:45Z

Border rounding should now be interoperable and well-specified, but that does still mean that the border color in this example depends on the scale factor (you can see it change by zooming in/out; it'll swap colors at some zoom levels). Is that ok, now that it's a consistent effect between browsers?

hober added the css-backgrounds-3 Current Work label Aug 11, 2022

chromium-wpt-export-bot mentioned this issue Oct 13, 2022

Snap Border, Outline, and Column-Rule Widths before Layout web-platform-tests/wpt#36189

Merged

sircumferencee mentioned this issue Feb 27, 2023

[css2?] Define when border rounding happens, and to which properties it applies #5210

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[css-backgrounds] Border width rounding affects collapsed border conflict resolution #7473

[css-backgrounds] Border width rounding affects collapsed border conflict resolution #7473

wangxianzhu commented Jul 7, 2022

tabatkins commented Feb 27, 2023

[css-backgrounds] Border width rounding affects collapsed border conflict resolution #7473

[css-backgrounds] Border width rounding affects collapsed border conflict resolution #7473

Comments

wangxianzhu commented Jul 7, 2022

tabatkins commented Feb 27, 2023