Re: [csswg-drafts] [css-borders] Add a 'hairline' border-width value (#3720)

I don't fully understand the danger of device-pixels, is the thrust of the argument: if we let people draw lines at 1dppx or 2dppx, it may look fine on their 96dpi display, but at 300dpi those features are now invisible?

I unfortunately have to deal a lot with displays that have a _native_ non-integer devicePixelRatio that are close to but not actually 96dpi. This means that not only are 1dppx alignment errors very obviously visible, but any user that uses the zoom function of their browser immediately breaks any layout that uses 1px boundaries, like the aforementioned `gap: 1px` because there's no other good way to draw border-collapsed style borders on top of a css grid. And due to not being snapped, this results in some gaps being anywhere from 0px to 2px wide.

Nearly all of my issues are solved by using `round(1px, var(--dpx))`.

The only other case where I've drawn something at 1dppx was a striped background gradient, where the goal was to have almost imperceptible striping. This was done with `max(1dppx, 0.5px)` because the effect looks better on high-dpi displays but needed to not become solid color on low-dpi.

---

I could see an argument where instead of giving access directly to dppx, you defined a hairline unit that was guaranteed to be an integer multiple of device pixels. To avoid the disappearance of features on high-dpi displays. But you'd need to modify layout so that boxes can't be laid out to sub-hairline alignments?

There would need to be an escape hatch, to allow users to layout boxes aligned with colored regions in images, which may have sub-hairline alignment of colored regions. For instance aligning a button on top of a background image, would look strange if :hover styles caused it to be 1dppx offset from the background due to hairline layout constraints.

So a hairline unit may not actually be a solution.

---

Print is definitely a concern as are non-rectilinear displays. The former has such high dpi that my issues with non-integer devicePixelRatio is moot: even if the pixels are fractional the printer has enough resolution beneath that to avoid visibly misaligning boxes. The latter I admit I don't comprehend the issue. The software canvas will be rectilinear pixels, but when rendered to the screen it will be mosaiced by software to an appropriate pattern for the display?

---


Without device pixels or hairline-aligned layout this always results in bad looking rendering when the device pixel ratio is non-integer.

```html
<style>
box {
    border: 1px solid black;
    background: black content-box;
    padding: 1px;
}
</style>
<box>x</box>
```

<img width="31" height="39" alt="Image" src="https://github.com/user-attachments/assets/f6de4e7e-9d8a-4b8a-b588-b4dacf4d286d" />

having access to rounding to device pixels may not solve every issue easily, but it does make them possible to solve. Grid layout gaps when the grid box itself is a non-integer number of device pixels wide can still only be solved with tedious `width: calc(math)` or using a container query to obtain inline-size and rounding down to the nearest multiple of dppx compatible with interior layout divisions. And yes I can use a short snippet of javascript to inject the `devicePixelRatio` as a custom property into the page, but I like to author css in such a way that it doesn't rely on the presence of javascript to function.

If you want to reduce the danger, expose the dppx keyword as a rounding mode only. It would mean that to round to multiples of dppx authors would need to do `round(nearest, 50px, round(up, 0px, dppx)`. Yes authors _can_ define their own `--dpx: round(up, 0px, dppx)` but that's opt-in and less of a foot-gun for the uninitiated?

---

possible final concern is how `dppx` or even `hairline` should behave in `scale: 0.5` or `zoom: 0.5` elements. Right now it is not possible for javascript to inject `--dpx` for individually scaled or zoomed elements, if its desirable to make the unit invariant to zoom. I'll note that it may actually be desirable to make it invariant to zoom, because some applications use zoomed iframes to simulate other display types inline. If dppx or hairline scales with the zoom, then the simulation is less accurate.

-- 
GitHub Notification of comment by webstrand
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3720#issuecomment-3755272929 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Thursday, 15 January 2026 14:58:02 UTC