[css-values-5][css-inline-3] Rounding to device pixels

[fantasai]

Following up on #3720... Several situations that were brought up as motivating use cases for env(hairline) were actually about forcing device-pixel rounding. This isn't something we really want authors to be thinking about normally--stylesheets peppered with device-pixel rounding functions would be a nightmare to understand and maintain.

Ideally the browser engine should handle rounding things wherever rounding is the right thing to do, so one question is: are there places where we should be doing device-pixel rounding that we aren't right now?

One place that comes to mind is line-height. If you have a fractional line height, your lines will not have consistent rhythm. Should line-height (and thus the lh unit) round to the nearest device pixel?

[frivoal]

Probably yes, though there's also a question of at what stage the rounding happens. We probably want computed value time, similar to how it happens for border width snapping (and that way it also influences the lh unit), but do we want a second round of rounding to apply to the logical line height / layout bounds as well.

[mindplay-dk]

Ideally the browser engine should handle rounding things wherever rounding is the right thing to do, so one question is: are there places where we should be doing device-pixel rounding that we aren't right now?

Borders, padding and margins is where this currently hurts the most.

I had to come up with a solution, because our designer came up with a double border on a very important input, and it comes out looking bad no matter what I do, so I decided to do some experiments:

https://stackblitz.com/edit/vitejs-vite-9tsxnhwr?file=src%2FApp.tsx

Zoom in and out in the browser, the issues with the "wonky" examples are obvious.

Zoom below DPR 1.0 and the "good" examples still look as good as they can under the circumstances.

I can't seem to break this - it "just works" as far as I can tell, and I don't understand why this isn't the default for border, padding and margin?

If you use flex-grow: 1 on 5 elements in a 502px container (on a display with DPR 1.00) of course some of the individual elements are going to be 100 device pixels and some will be 101 device pixels - this works as you'd expect, I think.

When would anybody want unequal left/right/top/bottom borders, padding or margins? This always looks bad.

If border/margin/padding are set to the same value, clearly someone wanted them to look the same, right?

I understand why this is not a "unit", in the sense of physics or mathematics or CSS units, and why it can't be.

This proposed hairline keyword works for borders only, and it's not really much use to me at all - the hairline is actually a rare edge case in most of the designs I've seen. The much more common use case is 2px or 3px which you can't count on at all right now to render consistently with design tools such Figma where our designed created it.

Practical example:

This is a 1px border on the inside, a 2px padding, and a gradient 3px background filling a margin.

That right border. 🥲

The fact that I have to resort to CSS-in-JS to solve this is sort of maddening.

But why do we have to fight the browser to make this work in the first place?

Honestly, if this gets standardized in a way where we have to put function calls everywhere to get the behavior most people would just naturally expect, I'll probably just write a postcss transform that applies the function everywhere where px is used with values under 4-5 or so.

Wouldn't it be much better if this "just worked"? Zoom in/out in the demo I posted and tell me this dosen't make way more sense? 😊

The intention when someone applies the same values to all 4 edges is fairly clear and unambiguous, is it not?