- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Thu, 02 Apr 2026 23:36:50 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-values-5][css-borders-4] Extending <line-width>`, and agreed to the following: * `RESOLVED: text-underline-width gets snapped as a border width` * `RESOLVED: stroke-width does not snap as a border width` * `RESOLVED: Try for gaps, if it's web-compatible.` <details><summary>The full IRC log of that discussion</summary> <emilio> TabAtkins: couple lines ago we resolved to add hairline to line-width (currently border- outline- column-rule widths)<br> <emilio> ... we resolved to add line-width to gap, stroke-width, and text-decoration-thickness<br> <kbabbitt> q+<br> <emilio> ... question is do we want to resolve that all those properties get pixel-snapped?<br> <emilio> q+<br> <emilio> ... are other properties we should add to this list<br> <florian> q+<br> <astearns> ack kbabbitt<br> <emilio> kbabbitt: my concern here would be webcompat with stroke-width<br> <emilio> ... because SVG does weird stuff with coordinate systems<br> <emilio> ... for existing values would like to check rendering<br> <fantasai> fantasai: We aren't snapping to 'px' though. We're snapping to device pixels.<br> <emilio> fantasai: just to clarify we won't snap to pixels, but device pixels<br> <emilio> kbabbitt: for gap it's also weird, having it a 1em default and snapping<br> <emilio> ... if it's not compatible I think it's fine<br> <emilio> florian: with the kind of snapping we'd only grow when under 1 dev pixel<br> <fantasai> emilio: For values higher than 1 pixel, the snapped value will always be less<br> <dholbert> q+<br> <astearns> ack emilio<br> <fantasai> (for values under 1 it snaps up to 1 pixel)<br> <kbabbitt> s/not compatible/web compatible/<br> <fantasai> emilio: I wouldn't do it for gap because small gaps are not that common<br> <fantasai> emilio: that seems a bit more risky becuase it does change layout<br> <fantasai> emilio: could be a bit confusing, particularly if you have some tiny gap that you've measured to fill exactly 100% and snapping makes you a little different<br> <fantasai> emilio: text-underline-thickness, uncontroversial<br> <fantasai> emilio: stroke-width I figured wouldn't affect layout so should be ok, but Kevin's right it might affect redering<br> <fantasai> TabAtkins: Fact that stroke-width is not border-snapped right now is observable<br> <fantasai> TabAtkins: that's why people shift their SVG by half a pixel, so it aligns perfectly<br> <fantasai> TabAtkins: but it would change the svgs in a noticeable way<br> <fantasai> emilio: but I think conceptually you want them snapped<br> <fantasai> kbabbitt: stroke-width anywhere other than svg?<br> <fantasai> TabAtkins: theoretically for text<br> <fantasai> emilio: but a page using a tiny scale, and then scaling the SVG<br> <fantasai> emilio: because it's pre-transform device pixels<br> <fantasai> emilio: Still might be worth trying<br> <fantasai> emilio: but I don't have high hopes there :)<br> <astearns> ack florian<br> <fantasai> florian: for gaps, I'd be inclined to try<br> <emilio> florian: when I got in the queue I wasn't aware of SVG weirdness<br> <emilio> ... for gaps I'd be inclined to try<br> <emilio> ... I think most of the time it won't matter. If you have a 1em gap it might be a bit tinier<br> <emilio> ... if you have a hairline it might be better if they're the same size<br> <astearns> ack dholbert<br> <emilio> dholbert: couple more factor, strokes there is a zero guarantee they're going to be a pixel-aligned shape<br> <emilio> ... so you're not gaining much there<br> <emilio> ... you have stroke-dasharray which you'd need to counter-snap<br> <emilio> ... for SVG strokes there's non-scaling-stroke<br> <Kurt> q+<br> <emilio> ... that is not exactly the same effect<br> <emilio> ... but is a bit similar and it might achieve some of the same results<br> <emilio> ... so in general I don't think doing this for SVG is worth it<br> <emilio> ... about gap, same concern as emilio, affects layout, and having animations that snap at different times is a bit unfortunate<br> <emilio> ... don't have a concrete testcase in mind, things that impact layout creates opportunities for that<br> <astearns> ack Kurt<br> <emilio> emilio: we do apply those to borders which do affect layout tho<br> <emilio> Kurt: more svg weirdness, what about textPath?<br> <emilio> ... do we align / snap the text?<br> <emilio> ... is the text in that path affected by that subpixel change?<br> <emilio> emilio: I _think_ it doesn't? But it might, SVG does weird stuff with strokes<br> <emilio> Kurt: would have to check<br> <Kurt> Confirmed strokeWidth does *not* impact textPath layout<br> <lea> presumably we only do so for styles != wavy or dotted, right?<br> <emilio> PROPOSED: text-underline-width gets snapped as a border width<br> <emilio> fantasai: for gap it depends on how small your gap is<br> <emilio> RESOLVED: text-underline-width gets snapped as a border width<br> <fantasai> s/it depends/benefit depends/<br> <emilio> PROPOSED: stroke-width does not snap as a border width<br> <emilio> RESOLVED: stroke-width does not snap as a border width<br> <emilio> emilio: would still be interesting to try<br> <emilio> kbabbitt: not much benefit tho<br> <emilio> dholbert: concern with gaps is why is it different from padding / margin?<br> <emilio> fantasai: gaps are more likely to be a small number<br> <emilio> ... they have the effect of looking like a line if you have a background<br> <emilio> ... a grid with gaps and a background is similar to borders<br> <emilio> florian: I'd be interested in margin / padding<br> <emilio> ... I don't think there's a rush but I think there's opportunity for that<br> <emilio> astearns: new issue for gap / margin / padding<br> <emilio> fantasai: that's more compat risky<br> <emilio> ... gaps are much more restrictive<br> <emilio> ... most of the time stuff is going to take the remaining stuff<br> <emilio> ... grid is designed around subtracting the gap<br> <emilio> ... for padding / margins etc there's more combinations that happen<br> <emilio> ... and hacks with negative margins to overlap stuff and so on<br> <emilio> ... layouts using calc() and so are more common<br> <emilio> ... for padding / margins is more risky than gaps<br> <florian> q?<br> <florian> q+<br> <emilio> ... for padding in particular you're often dealing with larger values<br> <emilio> emilio: gaps are also not always that small<br> <emilio> ... lots of "10px separation between buttons" and such things<br> <fantasai> s/remaining stuff/remaining space/<br> <emilio> fantasai: 10px and less is where I consider people noticing this<br> <emilio> ack florian<br> <astearns> ack florian<br> <emilio> florian: the case fantasai brought up where the gap makes the background show through<br> <emilio> ... so the gap in itself is a line<br> <emilio> ... so because we're doing snapping on many thing<br> <emilio> ... so I'd be inclined to try a bit more<br> <emilio> fantasai: with gap decorations you have the decoration and the gap inside the decoration<br> <emilio> ... and they can get small<br> <fantasai> emilio: Fine to try. A bit skeptical about compat<br> <fantasai> emilio: Worst case, can you remind me, did we resolve on adding a rounding function so that snapping (if you care about it) is doable?<br> <fantasai> PROPOSED: Try for gaps, if it's web-compatible.<br> <fantasai> RESOLVED: Try for gaps, if it's web-compatible.<br> <emilio> dholbert: one interesting thing is people polyfilling the gap decorations<br> <emilio> ... if we change behavior might cause cosmetic regressions<br> <emilio> ... not sure if some people actually do this tho<br> <emilio> kbabbitt: this is one where the only way to know it's to try<br> <emilio> astearns: need to add use counters where you detect a difference<br> <astearns> s/detect a difference/detect a difference in rendering both paths/<br> <fantasai> emilio: tricky to know if the dfiference is an improvement or a regression<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/13599#issuecomment-4181012196 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 2 April 2026 23:36:51 UTC