[css-backgrounds] Border width rounding affects collapsed border conflict resolution #7473
Labels
css-backgrounds-3
Current Work
Comments
chromium-wpt-export-bot
pushed a commit
to web-platform-tests/wpt
that referenced
this issue
Oct 13, 2022
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
chromium-wpt-export-bot
pushed a commit
to web-platform-tests/wpt
that referenced
this issue
Oct 13, 2022
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
chromium-wpt-export-bot
pushed a commit
to web-platform-tests/wpt
that referenced
this issue
Oct 14, 2022
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
chromium-wpt-export-bot
pushed a commit
to web-platform-tests/wpt
that referenced
this issue
Oct 14, 2022
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
chromium-wpt-export-bot
pushed a commit
to web-platform-tests/wpt
that referenced
this issue
Oct 15, 2022
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
chromium-wpt-export-bot
pushed a commit
to web-platform-tests/wpt
that referenced
this issue
Oct 15, 2022
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
chromium-wpt-export-bot
pushed a commit
to web-platform-tests/wpt
that referenced
this issue
Oct 15, 2022
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
chromium-wpt-export-bot
pushed a commit
to web-platform-tests/wpt
that referenced
this issue
Oct 17, 2022
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
chromium-wpt-export-bot
pushed a commit
to web-platform-tests/wpt
that referenced
this issue
Oct 18, 2022
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
chromium-wpt-export-bot
pushed a commit
to web-platform-tests/wpt
that referenced
this issue
Oct 18, 2022
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
chromium-wpt-export-bot
pushed a commit
to web-platform-tests/wpt
that referenced
this issue
Oct 18, 2022
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
chromium-wpt-export-bot
pushed a commit
to web-platform-tests/wpt
that referenced
this issue
Oct 18, 2022
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
aarongable
pushed a commit
to chromium/chromium
that referenced
this issue
Oct 18, 2022
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}
chromium-wpt-export-bot
pushed a commit
to web-platform-tests/wpt
that referenced
this issue
Oct 18, 2022
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}
chromium-wpt-export-bot
pushed a commit
to web-platform-tests/wpt
that referenced
this issue
Oct 18, 2022
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}
moz-v2v-gh
pushed a commit
to mozilla/gecko-dev
that referenced
this issue
Oct 26, 2022
…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
jamienicol
pushed a commit
to jamienicol/gecko
that referenced
this issue
Oct 31, 2022
…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
|
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? |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
http://jsfiddle.net/zmav431j/
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: