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

All right, disappointingly, we didn't come to resolution today, because `env(hairline)` was blocked on us first solving the more general problem of actual device-pixel lengths and/or border-rounding. [My Agenda+ request](https://github.com/w3c/csswg-drafts/issues/3720#issuecomment-3226053230) was specifically trying to push those more general problems to the side *so they stop blocking this issue from 2019, which has been around since many years earlier*.

I still don't understand the logic behind this blocking. Assuming that someone comes up with the perfect dppx solution tomorrow, the use-cases for "I want this non-border property to be the same size as the hairline" still exists, so we'll still want to expose env(hairline). The use-case is identical for "I want this non-border property to be the same size as my `medium` border", but `medium` is just a synonym for `3px`, so that's completely doable; `hairline` doesn't have an exact synonymous size, by the nature of its definition.

The big objection from @fantasai, as far as I understood it, is the possibility of people misusing `env(hairline)` for things where they "really want" a device pixel length. Is this correct, @fantasai?

If so, both I and @emilio argued in the discussion that this isn't a meaningful problem in practice, and in fact it will often be *avoiding* a footgun. Most use-cases where people *think* they want device pixels, they actually just want "smaller than 1px and device-pixel-snapped", which `env(hairline)` provides (so long as the width is already flush with a dp boundary, of course, but that's no different than 1px only being crisp at a dp boundary; it usually will be). In many cases, if device pixels were suddenly 1/10th the size, their use-case would *break* if we actually gave them that size.

Even in cases where people *legitimately* do want device pixels, using a hairline that might be a few dp in size is almost never *bad*, it's just *not quite optimal*. That's not, imo, enough of a problem to object to the length, given the practical use-cases presented.

Device pixels are a *very* dangerous thing to actually expose to people. Authors have ways to obtain that length if they really want, via a little bit of scripting, but making it easy to obtain in plain CSS is dangerous. As we move forward I think it's likely we *will* expose more dp details to authors, but in use-case-specific ways, where it's harder to misuse.


-------

So, in conclusion:

* "Real" device pixels continue to be a dangerous thing to expose, and most people asking for it don't actually want it and would have their pages break if we gave it to them.
* People using `env(hairline)` when they "really want" device pixels is totally fine in practice. Using it is often *better* than using "real" device pixels, and in the rare cases where their use-case is actually reasonable to solve with real device pixels, using `env(hairline)` instead doesn't *break* anything, it just isn't *quite as optimal* as real device pixels would be (on theoretical future ultra-high-res screens).
* Use-cases for "real" device pixels are extremely varied, and often pull in questions of dp-snapping of geometry, of responding to zoom, of printing and variable color vs black resolution, etc. There is **no generic solution** that solves all the dp-related use-cases.
* There are many practical use-cases for a hairline width (or something very similar, per previous point) outside of borders and rules, so just adding a `hairline` border-size keyword that computes to a <=1px length isn't sufficient.

So, my requested resolution next time is that we affirmatively push dp-related shenanigans to a separate issue, and resolve on adding `hairline` to `<line-width>` in the Borders spec and `env(hairline)` to the Env spec.

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


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

Received on Wednesday, 14 January 2026 18:26:09 UTC