- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 12 Feb 2025 17:32:18 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-borders] Add a 'hairline' border-width value`. <details><summary>The full IRC log of that discussion</summary> <noamr> TabAtkins: people look for a hairline border-width, usually "as thinner as visible", something like device pixels<br> <noamr> TabAtkins: we saw that it's not something that we want to expose because it varies across devices. Authors don't anticipate this change<br> <noamr> TabAtkins: we'd like to avoid this<br> <noamr> TabAtkins: device pixels is not always well defined<br> <noamr> TabAtkins: also it's not clear what happens if it's zoomed<br> <noamr> TabAtkins: this can become very small<br> <noamr> TabAtkins: kbabbitt suggested to declare that hairline is exposed as 1px, but rendered in an implementation-defined way, probably something like device pixel aligned<br> <smfr> q+<br> <Rossen6> q+<br> <joshtumath> q+<br> <noamr> TabAtkins: we can define how hairline works for each CSS property, e.g. border/column etc<br> <noamr> TabAtkins: this would allow accessibility options for users who need to scale the hairline, and this won't mess up design<br> <flackr> q+<br> <noamr> TabAtkins: I suggest we take Kevin's proposal and add it to the border-spec and columns spec for multicol rule, perhaps to other specs that need this<br> <emilio> q+<br> <Rossen6> ack smfr<br> <noamr> smfr: I'm concerned that the painted width is different from the background. it means that the background is going to leak out of the hairline<br> <flackr> q- same q as smfr<br> <flackr> q-<br> <noamr> smfr: we can apply the same heuristic, but it seems weird that the geometry doesn't match<br> <Rossen6> q-<br> <noamr> TabAtkins: we should define that background area extends, but doesn't paint<br> <noamr> smfr: it doesn't work with box-shadow, adjacent boxes<br> <noamr> TabAtkins: I think it's a good thing, but probably usually fine<br> <kbabbitt> q+<br> <dholbert> RE the gap, you'd *only* get a gap on a HiDPI screen, which is weird<br> <noamr> smfr: my suggestion would be that the border-width would be some fractional implementation defined value rather than being different<br> <noamr> Rossen: I can see how this would work if it takes the outermost part of the pixel, e.g. there should never be background that extends out, same for shadows etc. Anywhere else, you're asking for all of the trouble smfr pointed out<br> <noamr> TabAtkins: I was describing it wrong. The details in the thread are to have it on the outside, exactly for these issues<br> <noamr> TabAtkins: let's go with that<br> <emilio> It reveals the underlying background unless it uses `padding-box` or so right?<br> <TabAtkins> yes<br> <noamr> Rossen: it's going to break things that align, like snapping/abs position etc<br> <noamr> joshthumath: similar note, the stripes function (not implemented yet). what would happen when we want multiple hairline-width stripes?<br> <noamr> TabAtkins: I think hairline wouldn't be a generic width value, it's a value for specific properties like border-width<br> <kizu> Fun fact: Chrome paints `2px double` border as 2 hairline lines with a gap<br> <noamr> TabAtkins: we'd probably won't paint stripes in a hairline-widdth border<br> <Rossen6> ack emilio<br> <Rossen6> ack joshtumath<br> <joshtumath> s/joshthumath/joshtumath/<br> <noamr> emilio: I was going to raise a lot of smfr's concerns. I don't object to hariline value, but I think we can change the border bounding algorithm we have to bound towards the nearest hairline<br> <noamr> emilio: the UA already aligns pixels e.g. 0.01 border-width to something that's hairline-like<br> <noamr> emilio: I would prefer to tweak the current border-width rounding to a hairline<br> <noamr> emilio: for shadows, it's not a huge issue. maybe it's just a matter of implementing stripes<br> <noamr> emilio: I much rather expose the current border-width rounding and allowing the UA to tweak it, or expose a round-ish function<br> <smfr> Blink and WebKit round a 0.0001px border up to a hairline; Gecko doesn't draw it<br> <noamr> Rossen6: also what does this mean for two hairline borders to collapse<br> <emilio> smfr: Probably pixel precision issue, `0.01px` does get rounded up<br> <noamr> kbabbitt: I heard that in border the hariline would be painted on the outermost hairline, and the background would fill under that<br> <noamr> TabAtkins: it's not that the background fills in, it's that the background is drawn under the border area<br> <noamr> kbabbitt: I want to avoid something where when a designer defines something on a high DPI device it breaks on a different device with lower DPI<br> <noamr> Rossen6: I'm not sure where this was going. There are still some questions<br> <noamr> Rossen6: this sounds like a great proposal and something that people are trying to do today<br> <noamr> Rossen6: is that something we want to pursue? Do we have a good starting point?<br> <noamr> TabAtkins: we don't have all the details yet<br> <noamr> TabAtkins: I propose we take this back to the issue<br> <emilio> TabAtkins: wdyt of `border-snap(<length>)` which just snaps that length as a border or so?<br> <TabAtkins> emilio, that's part of why I don't *want* to rely on border rounding. "if you want a hairline, put in a value that is *probably* too small to actually paint, but not *too* small, and you have to guess what "too small" means"<br> <emilio> I think it's not incompatible with `hairline`, if we make hairline resolve to pixels and affect geometry...<br> <emilio> fair<br> <noamr> leaverou/leaverou_: join the call?<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-2654408011 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 12 February 2025 17:32:19 UTC