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

> I still don't understand the logic behind this blocking.

As far as I am concerned, I am not strictly blocking `env(hairline)` until pixel snapping and such is solved. But I am saying we should take things one step at a time. Having a `hairline` keyword for `border-width` and the like does not solve all the use cases, but in the cases it does solve, it allows authors to express a clear intent, does exactly the right thing, and nothing more. It is both useful and safe, so I think we should do it immediately, and look how far that gets us.

Specifically, I think we should:
* add `hairline` to `<line-width>` (which is already used in `border`, `outline`, `gap-rule`)
* extend the syntax to allow `<line-width>` in a few of properties which arguably should have had it all along, but never bothered to go beyond length because the other values of `line-width` weren't thus far very useful: `padding`, `margin`, `text-decoration-thickness`, `gap`, `box-shadow-spread`, `stroke-size`

I agree that `env(hairline)` can be used to do useful things, and is a more generic tool. But I see that as a double edged sword:
* On the plus side, it can be used in places where we have not (yet) adjusted the grammar to allow a direct `hairline` keyword as part of the syntax's property, so people can do hairliny things without having to wait for the WG to accommodate their needs one by one, which relieves the WG of having to accommodate their needs one by one.
* On the flip side, because it's generic, it can be used in places where it doesn't really make sense. The problem with giving people a tool that is generically applicable, but does not necessarily make sense in a general context is that since it does something, people will use it and get something out of it, but the something may not be well behaved, and we get sites that work in some context, but are user hostile in others, work great on some device and poorly on others… This is especially true given that it can be used in `calc()`, which makes it effectively equivalent to a unit, and so people can use it not just for a hairline, but also to make something 300 hairlines tall, or giving things an aspect ratio of 1hairline to 1px, or whatever. Granted, sizing things in hairlines is not as brittle than sizing things in dpx. But it isn't a _generally_ sensible thing, so it is not _generally_ robust.

My proposal is not that we therefore never add `env(hairline)`. Rather, it is that we start with adding `hairline` to `<line-width>`, and using `<line-width>` a little more broadly as discussed above, and then wait to see what people do with it. My expectation is that:
* this already solves a substantial part of the problem space, especially if we give time to people to think creatively about how this interacts with the rest of the css toolbox
* this lets us separately look at the rest of the unsolved use cases, and possibly come up with additional solutions that address some subclass of them well without having weird side effects.

It is very possible that having done that, we will still conclude that `env(hairline)` is the best compromise of a tool that solves most problems without too many side effects. But I am not convinced of that, and I suspect that if we first pursue adding `hairline` to `<line-width>` and using `<line-width>` a little more broadly, we will find that we have solved more than we thought, and with a smaller reminder left to solve, we may be able to identify better solutions for that.

I am open to being proven wrong, and to the possibility that `env(hairline)` is indeed as good as its going to get. But my request is that we first do `hairline` with `<line-width>`, while we talk about `env(hairline)` and what else we might do to solve the rest of the solvable use cases.

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


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

Received on Tuesday, 20 January 2026 15:57:30 UTC