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

emilio · 2020-06-14T09:28:00Z

See https://crisal.io/words/2020/06/13/rounding-borders.html

At least the rounding up to device pixels happens consistently at computed value time:

Shipping Gecko and WebKit (my post was wrong, Blink and WebKit diverge, will fix) also floor to dev pixels at computed value time. Blink floors at rendering time, which I think is more unfortunate.

emilio · 2020-06-14T09:37:59Z

Did some digging and Blink behavior is inherited from WebKit, but WebKit changed it to match Gecko in https://bugs.webkit.org/show_bug.cgi?id=156121.

emilio · 2020-06-14T09:55:32Z

cc @mrego who was touching border rounding in Blink recently.

gsnedders · 2020-07-09T18:56:33Z

On the whole this ties into the larger issue as to whether we should define rounding behaviour in CSS, which… we appear not to have an issue for?

graouts · 2021-03-08T14:31:52Z

I came across this trying to fix css-backgrounds/animations/border-width-interpolation.html for WebKit. This test should be changed to not test values where this behavior is somewhat undefined, filed WPT issue #27934.

… open discussion (see w3c/csswg-drafts#5210). This test should not be about testing that behavior but rather whether values are interpolated correctly when "initial" or "unset" is used as a "from" value. To do this we change the "to" value to always have integer values at the tested offsets.

How border-width values should be rounded in the computed style is an open discussion, per [csswg-drafts issue #5120](w3c/csswg-drafts#5210). This test should not be about testing that behavior but rather whether values are interpolated correctly when `initial` or `unset` is used as a "from" value. To do this we change the "to" value to always have integer values at the tested offsets.

…oes not yield float values, a=testonly Automatic update from web-platform-tests Ensure border-width interpolation test does not yield float values How border-width values should be rounded in the computed style is an open discussion, per [csswg-drafts issue #5120](w3c/csswg-drafts#5210). This test should not be about testing that behavior but rather whether values are interpolated correctly when `initial` or `unset` is used as a "from" value. To do this we change the "to" value to always have integer values at the tested offsets. -- wpt-commits: 7e343597a6abe5601ebd686ba34ffba3dc95d3cf wpt-pr: 27934

wangxianzhu · 2022-07-07T19:34:25Z

Did some digging and Blink behavior is inherited from WebKit, but WebKit changed it to match Gecko in https://bugs.webkit.org/show_bug.cgi?id=156121.

Blink diverged from WebKit more after https://codereview.chromium.org/2640143005 (support subpixel layout of borders, April 2017).

Browser: Rounding in layout / Rounding in computed style:
Firefox: Yes / Yes
WebKit before April 2016: Yes / No
WebKit after April 2016: Yes / Yes
Blink before April 2017: Yes / No
Blink after April 2017: No / No
Possible future Blink change: Yes / Yes

progers · 2022-09-29T21:32:40Z

Chromium is attempting to unify on the behavior used by Gecko and WebKit:
blink-dev intent-to-ship: https://groups.google.com/a/chromium.org/g/blink-dev/c/0uq_S5p6uZg/m/ReHlihKaAwAJ
chromium bug: https://crbug.com/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 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}

tcaptan-cr · 2022-10-21T01:39:04Z

The Chromium change that unifies the behavior with Gecko and WebKit is now complete, and we could update the spec to define the border-width rounding at computed value time.

A proposed wording for the spec definition could be:

The border-width length should be snapped to the nearest device pixel at computed value time
based on the following rounding formula:
  If the border-width length is greater than 0 device px and less than 1 device px
  it should be rounded up to 1 device px.

  If the border-width length is greater than 1 device px
  it should be floored down to the nearest device pixel.

The clarification of the rounding behavior has also been discussed in issue 2114

…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

dbaron · 2022-10-27T00:09:24Z

A few thoughts on a spec definition for this:

Given that it applies to multiple properties (I think border-*-width, outline-width, and column-rule-width), you want to have a definition in one place that can be referenced by the definitions of all three properties. So I'd suggest something like:

To snap a length as a border width means to convert that length (presumed to already be nonnegative) as follows:

if the length is greater than 0 and less than 1 device pixel, it should be rounded up to 1 device pixel;

if the length is greater than 1 device pixel, it should be rounded down to the nearest integer number of device pixels.

Given a definition like that, the "Computed value" lines could then say something like "absolute length, snapped as a border width" where "snapped as a border width" links to the above definition.

…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

css-meeting-bot · 2022-11-16T17:50:36Z

The CSS Working Group just discussed [css2?] Define when border rounding happens, and to which properties it applies, and agreed to the following:

RESOLVED: Add this definition to values-4 and evaluate new definition against existing test suite.

The full IRC log of that discussion

<astearns> topic: [css2?] Define when border rounding happens, and to which properties it applies
<astearns> github: https://github.com//issues/5210
<fantasai> -> https://github.com//issues/5210#issuecomment-1292794138
<dandclark> dbaron: There have beeen differences in how border rounding works between impls.
<dandclark> dbaron: ??? landed change to make Chromium match webkit, gecko.
<dandclark> ...: we think border-rounding is interop now.
<dandclark> ...: given this, and that there's dependency on it which may increase, we should spec it.
<dandclark> ...: emilio opened this 2+ years ago, does he have anything to add?
<dandclark> emilio: <missed>
<dandclark> dbaron: In last comment I attempted to write definition in spec language. Other folks from other engines should look. If we're ok with it, lets move forward and try to spec it.
<fantasai> -> https://github.com//issues/5210
<dbaron> s/???/Traian/
<dandclark> emilio: I was misreading, I think that definition is correct.
<dandclark> astearns: This is matching existing tests?
<dandclark> dbaron: Yes there are various tests. I think there are a bunch of wpt tests for this behavior.
<dandclark> ...: I know when Trian was making chromium changes, making changes caused other engines to fail. Encouraged him to test only interoperable behavior.
<dbaron> s/other engines to fail/Chromium to fail some existing tests/
<astearns> ack fantasai
<dandclark> asterns: Proposed resolution: Add this definition to spec and evaluate new definition against existing test suite.
<dandclark> fantasai: Propose to add to values-4
<dandclark> dbaron: <missed> I don't strongly about which spec, I leave to editors.
<dandclark> asterns: Proposed resolution: Add this definition to values-4 and evaluate new definition against existing test suite.
<dandclark> RESOLVED: Add this definition to values-4 and evaluate new definition against existing test suite.
<dbaron> (and the issue should have links to the WPT PR)

MrHBS · 2023-02-27T19:23:37Z

@emilio @dbaron @fantasai Would one of you guys do the edit? Or I'll try to open a PR.

…e it in several properties to snap computed values. #5210

tabatkins · 2023-02-27T20:29:02Z

Done! Sorry, the resolution came in while I was on birthday vacation, so I missed it.

MrHBS · 2023-02-27T20:51:35Z

@tabatkins Very nice! Thank you! Just 2 more things to mention:

1 - You might want to look at #7473 and #2114 to see if they are still relevant after this change.

2 - CSS Cascading and Inheritance says:

A used value is in principle ready to be used, but a user agent may not be able to make use of the value in a given environment. For example, a user agent may only be able to render borders with integer pixel widths and may therefore have to approximate the used width.

I think this needs a tweak since border widths are always integers now?

tabatkins · 2023-02-27T21:16:12Z

For 1, thanks, I've commented or closed, as appropriate.

For 2, not necessarily - there's nothing in CSS requiring that a px is an integer multiple of device pixels, so that statement can still be reasonable. ^_^

gsnedders added the css-backgrounds-3 Current Work label Jul 9, 2020

fantasai added css-backgrounds-4 and removed css-backgrounds-3 Current Work labels Oct 30, 2020

emilio mentioned this issue Feb 23, 2021

docs.google.com - Items from the drop-down menu are flickering when moving the mouse up and down webcompat/web-bugs#66960

Closed

karlcow mentioned this issue Mar 1, 2021

www.friendlyarm.com - Product images and details are no fully visible with 150% zoom webcompat/web-bugs#62753

Closed

graouts mentioned this issue Mar 8, 2021

Ensure border-width interpolation test does not yield float values web-platform-tests/wpt#27934

Merged

wangxianzhu mentioned this issue Jul 7, 2022

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

Open

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

dbaron added the Agenda+ label Oct 27, 2022

Loirooriol mentioned this issue Oct 30, 2022

with the background-position property, where is the 50% position decision? #7982

Open

atanassov added this to Agenda+ in November 30 2022 Nov 16, 2022

fantasai added css-values-4 Current Work Needs Edits labels Nov 16, 2022

css-meeting-bot removed the Agenda+ label Nov 16, 2022

mozilla-apprentice mentioned this issue Nov 16, 2022

[css2?] Define when border rounding happens, and to which properties it applies mozilla/wg-decisions#956

Closed

atanassov removed this from Agenda+ in November 30 2022 Nov 22, 2022

tabatkins added a commit that referenced this issue Feb 27, 2023

[css-values-4][various] Define 'snapped as a border width', and invok…

29b1dae

…e it in several properties to snap computed values. #5210

tabatkins closed this as completed Feb 27, 2023

tabatkins added Closed Accepted by CSSWG Resolution Needs Edits and removed Needs Edits labels Feb 27, 2023

tabatkins removed the Needs Edits label Feb 27, 2023

Loirooriol mentioned this issue Nov 26, 2023

[css-borders] Add a 'hairline' border-width value #3720

Open

SebastianZ added css-backgrounds-3 Current Work and removed css-backgrounds-4 labels Feb 12, 2024

nicoburns mentioned this issue Apr 11, 2024

Better support for different pixel densities chearon/dropflow#16

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

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

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

emilio commented Jun 14, 2020 •

edited

Loading

emilio commented Jun 14, 2020 •

edited

Loading

emilio commented Jun 14, 2020

gsnedders commented Jul 9, 2020

graouts commented Mar 8, 2021 •

edited

Loading

wangxianzhu commented Jul 7, 2022

progers commented Sep 29, 2022

tcaptan-cr commented Oct 21, 2022

dbaron commented Oct 27, 2022

css-meeting-bot commented Nov 16, 2022

MrHBS commented Feb 27, 2023

tabatkins commented Feb 27, 2023

MrHBS commented Feb 27, 2023

tabatkins commented Feb 27, 2023

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

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

Comments

emilio commented Jun 14, 2020 • edited Loading

emilio commented Jun 14, 2020 • edited Loading

emilio commented Jun 14, 2020

gsnedders commented Jul 9, 2020

graouts commented Mar 8, 2021 • edited Loading

wangxianzhu commented Jul 7, 2022

progers commented Sep 29, 2022

tcaptan-cr commented Oct 21, 2022

dbaron commented Oct 27, 2022

css-meeting-bot commented Nov 16, 2022

MrHBS commented Feb 27, 2023

tabatkins commented Feb 27, 2023

MrHBS commented Feb 27, 2023

tabatkins commented Feb 27, 2023

emilio commented Jun 14, 2020 •

edited

Loading

emilio commented Jun 14, 2020 •

edited

Loading

graouts commented Mar 8, 2021 •

edited

Loading