- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Wed, 04 Mar 2026 18:05:25 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-borders] Add a 'hairline' border-width value`, and agreed to the following:
* `RESOLVED: Add hairline to <line-width>.`
* `RESOLVED: Add <line-width> to gap and text-decoration-thickness and stroke-width.`
* `RESOLVED: Add round(line-width, ...).`
<details><summary>The full IRC log of that discussion</summary>
<emilio> TabAtkins: I've read the pending comments<br>
<emilio> ... preference is to accept emilio's proposal<br>
<Rossen> emilio's proposal "https://github.com/w3c/csswg-drafts/issues/3720#issuecomment-3762832472"<br>
<fantasai> florian's proposal https://github.com/w3c/csswg-drafts/issues/3720#issuecomment-3773651216<br>
<emilio> ... I disagree with florian's objection to env(hairline)<br>
<emilio> ... we want hairline instead of dppx<br>
<emilio> ... authors can misuse dppx<br>
<emilio> ... avoiding that accidental user harm is why we want hairline in general<br>
<fantasai> I think y'all mean `dpx` (a theoretical length), not `dppx` (a resolution)<br>
<emilio> ... the harm florian is concerned about is that they can use env(hairline)<br>
<emilio> ... in very unreasonable ways<br>
<Rossen> q?<br>
<emilio> ... such like `height: calc(500 * env(hairline))<br>
<emilio> ... most of the harm is doable by using a small width manually<br>
<emilio> ... e.g if you add an aspect ratio with .1px<br>
<emilio> ... the very ability that env(hairline) introduces is not new<br>
<emilio> ... if they are shooting themselves in the foot<br>
<emilio> ... given there are use cases for hairline for things that aren't line widths<br>
<emilio> ... and harm is that if they do weird things they get weird results<br>
<emilio> ... I think that outweights it<br>
<emilio> florian: I think my opinion goes the other way<br>
<emilio> ... I don't object to env(hairline) forever<br>
<emilio> ... we can solve a large part to add hairline to some properties<br>
<emilio> q+<br>
<emilio> ... proposed padding / margin / text-decoration-thickness / ...<br>
<emilio> ... they don't accept line width because those weren't super useful<br>
<emilio> ... if we add that we'd solve a large enough chunk of it<br>
<emilio> ... if we give people time for that<br>
<emilio> ... then we can look at what's left and maybe be able to find a more tailored solution<br>
<emilio> ... rather than env(hairline) which addresses what's left and some more<br>
<emilio> ... I'm concerned about people doing silly things by using env(hairline) everywhere you can use a length<br>
<emilio> ... not objecting forever<br>
<emilio> ... but suggest we start with something else and see if we can find something better<br>
<emilio> ... maybe we can't<br>
<emilio> ... extending line-width to a few more properties<br>
<fantasai> scribe+<br>
<emilio> TabAtkins: florian, would you object to border-rounding function given it does offer the same functionality in a longer to spell way<br>
<fantasai> TabAtkins: Florian, would you object to border-rounding function?<br>
<emilio> florian: not a formal objection but let's start with the narrow subset but let's start narrower for the same reasons<br>
<fantasai> emilio: I don't think Florian's proposal quite works.<br>
<fantasai> emilio: If you extend <line-width> to padding etc. a very common use case is, I have 2 hairlines, now I have to account for both, now I need to multiply.<br>
<fantasai> emilio: You can't do margin-left: -2*hairline;<br>
<Rossen> ack emilio<br>
<fantasai> emilio: There's also a lot of extra complexity from exposing <line-width> more places<br>
<fantasai> emilio: Then you have to explain why hairline works in padding but not some other random property.<br>
<fantasai> emilio: So I do still think that env(hairline) solves more use cases.<br>
<fantasai> emilio: I don't think they're in the .1% of use cases we'd be fine not addressing.<br>
<emilio> fantasai: we'd propose adding hairline to line-width and expending line-width to gap / text-decoration-thickness<br>
<emilio> ... if we only provide env(hairline) then authors would use it for rounding to dev pixels<br>
<TabAtkins> yeah I like `round(border, Xpx)`, indeed<br>
<emilio> ... if there are specific use cases we need to solve we should look at them and see if we can solve them directly<br>
<emilio> ... if we can't solve them then we can do that<br>
<emilio> ... for the use cases we should be using something else and hairline would allow you to hack around them<br>
<emilio> q+<br>
<Rossen> ack fantasai<br>
<emilio> ... and not tempt authors to do things that can be problematic<br>
<smfr> q+<br>
<Rossen> ack emilio<br>
<fantasai> emilio: Don't disagree with that. Maybe adding `border` keyword or `device-pixel` keyword to `round()`. Better way to snap to pixel grid than hacking around with `env(hairline)`.<br>
<fantasai> emilio: I think we should do those, too.<br>
<fantasai> emilio: env(hairline) is then just a smaller version. I think it's still probably useful?<br>
<TabAtkins> env(hairline) === round(border, .1px), yeah<br>
<TabAtkins> so if we expose border rounding *at all* we're exposing the hairline width<br>
<fantasai> emilio: But idk, I think just extending <line-width> to a few more properties is not enough.<br>
<fantasai> emilio: I've seen people stashing device pixel in a custom property and using it.<br>
<TabAtkins> and env(hairline) is *just slightly* annoying to type anyway so it's not easy to reach for<br>
<fantasai> emilio: To Tab's point, it's already obvious if you're using `env(hairline)` for this, it's obviously quirkcy compared to using a dpx unit<br>
<Rossen> ack smfr<br>
<fantasai> smfr: I find `border` keyword in `round()` is weird, what's border doing here, I think if we do this we need a new keyword<br>
<emilio> smfr: If we decide having this round behavior it needs a new word<br>
<TabAtkins> I don't care how we spell it, `border-round(Npx)` is fine<br>
<astearns> match-border<br>
<fantasai> fantasai: I would suggest `line-width`<br>
<TabAtkins> or that, yeah<br>
<fantasai> round(line-width, ...)<br>
<fantasai> emilio: That's reasonable to me. Less confusing.<br>
<florian> q+<br>
<fantasai> emilio: Happy to swap around names.<br>
<emilio> florian: I hope I'm being paranoid<br>
<Rossen> ack florian<br>
<fantasai> florian: I hope I'm being paranoid, but I would hate it if we discover that some framework sets root font size to 15 hairlines and that works for some devices and not others.<br>
<emilio> ... I'd hate it that some framework has set `:root { font-size: calc(15 * env(hairline)) }` or something<br>
<fantasai> Rossen: Can we propose a resolution and move forward?<br>
<Rossen> ack fantasai<br>
<emilio> fantasai: multiple things have been proposed and we should go through them 1 by 1<br>
<emilio> ... we'd probably object to env(hairline)<br>
<emilio> ... we can go through things 1 by 1<br>
<TabAtkins> you can't object to env(hairline) while allowing round(line-width, ...) :((((((<br>
<fantasai> PROPOSED: Add hairline to <line-width>.<br>
<fantasai> PROPOSED: Add <line-width> to gap and text-decoration-thickness and stroke-width.<br>
<fantasai> PROPOSED: Add round(line-width, ...).<br>
<emilio> q+<br>
<TabAtkins> it just means that we need to warn authors to use `round(line-width, .1px)` rather than `round(line-width, .0001px)` due to rounding differences in browsers<br>
<Rossen> ack emilio<br>
<fantasai> RESOLVED: Add hairline to <line-width>.<br>
<fantasai> RESOLVED: Add <line-width> to gap and text-decoration-thickness and stroke-width.<br>
<TabAtkins> I'm gonna have to work real hard to make the advisement not sound passive-aggressive<br>
<fantasai> RESOLVED: Add round(line-width, ...).<br>
<emilio> I agree with TabAtkins on ^ fwiw :)<br>
<emilio> But alas<br>
<emilio> fantasai: we should go through some of these use cases<br>
<emilio> ... like gap / line-height should maybe snap to device pixels by default<br>
</details>
--
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3720#issuecomment-3999235838 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 4 March 2026 18:05:26 UTC