- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Wed, 10 Dec 2025 17:52:30 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-text-decor] Rounding of text-decoration-thickness`, and agreed to the following: * `RESOLVED: Snap text-decoration-thickness as a border width (https://drafts.csswg.org/css-values-4/#snap-a-length-as-a-border-width) at used-value time` <details><summary>The full IRC log of that discussion</summary> <ydaniv> emilio: this is about how text-decoratoin-thikness is rounded<br> <ydaniv> ... seems wierd to have a different algo<br> <TabAtkins> from-font<br> <ydaniv> ... also there's the whole auto vs. from-font<br> <ydaniv> ... should we do it at compute value time or used value time, is the question<br> <kizu> q+<br> <Rossen3> ack dbaron<br> <ydaniv> dbaron: this is a space of stuff where I have stong opinion, not really CHrome position<br> <ydaniv> ... I think I agree that we do want something that causes thikness to be consistent<br> <ydaniv> ... with borders we align other things, and need to have it consistent, so that top and bottom edges snap, and also layout concerns<br> <ydaniv> ... if someone has a specific text decor thikness you have to something to prevent [missed]<br> <fantasai> +1 to dbaron<br> <Rossen3> ack kizu<br> <dbaron> s/strong opinion/strong opinions from back when I worked on this stuff in Gecko/<br> <ydaniv> kizu: wanted to add about rounding of text decor, maybe also add some min value, not 0<br> <dbaron> s/prevent [missed]/prevent the text decoration from being a different apparent thickness on different lines as a result of shifts in the subpixel positions of the lines/<br> <ydaniv> ... it's a very common case when you add value based on font-size, it's easy to make it small enough, so when zooming or changing size it becomes close to 0<br> <emilio> q+ to say that is exactly what borders do ;)<br> <ydaniv> ... but this has a strong meaning<br> <ydaniv> ... so common practie is to wrap with clamp and a min value, so would be nice to introduce a way to clamp and not introduce a footgun<br> <Rossen3> ack emilio<br> <Zakim> emilio, you wanted to say that is exactly what borders do ;)<br> <dbaron> (btw, for borders the "affects layout" aspects mean that the snapping needs to affect computed values, I think... whereas for text decorations I don't think computed versus used mattters as much)<br> <ydaniv> emilio: that is exactly what borders do, any non 0 value is rounded up to 1px<br> <ydaniv> ... my proposal fixes that<br> <fantasai> dbaron, I don't think affecting layout needs to affect computed value<br> <ydaniv> dbaron: I agree it should be the same, but not necessarily have to match borders<br> <ydaniv> emilio: even if we need to compute at used value time....<br> <ydaniv> fantasai: yes, we should floor to 1 px, unless specifying 0<br> <dbaron> (or at least I *think* it's computed value time... not enirely sure)<br> <ydaniv> ... not convinced about the think with borders<br> <ydaniv> ... for borders with layout calc you need to snap it<br> <ydaniv> emilio: there's an issue with CSSOM API to get the correct value<br> <ydaniv> ... for borders, not proposing to change it, I agree that we can make it used value time<br> <Rossen3> q?<br> <ydaniv> fantasai: don't have a strong opinion on used/computed, just need to specify that we should snap on thikness of 1 px, and align on the grid when drawn<br> <Rossen3> ack fantasai<br> <fantasai> s/1 px/1 device pixel/<br> <ydaniv> Rossen3: other feedback to emilio?<br> <lea> q?<br> <ydaniv> fantasai: also snap to device pixel<br> <Rossen3> ack dbaron<br> <ydaniv> dbaron: all arguments here also apply to text-decor-offset<br> <ydaniv> fantasai: not sure about that, if the offset is on the pixel you want to snap to 0<br> <lea> q+<br> <ydaniv> dbaron: you're right that is different, but the thing why we want to snap still applies<br> <emilio> https://drafts.csswg.org/css-values-4/#snap-a-length-as-a-border-width is pretty explicitly device pixels<br> <fantasai> We're snapping to device pixels, not CSS px units<br> <ydaniv> fantasai: it's that you have to draw the line on the pixel grid, that calc should be done when you figure out where to draw<br> <Rossen3> ack lea<br> <ydaniv> leaverou: why are we rounding at all?<br> <ydaniv> fantasai: because you don't want the underline to be not drawn at all, and you want it to be on the correct position on the pixel grid<br> <ydaniv> ... you wan't it to be consistent<br> <TabAtkins> yup, pixel grid is very visually important for the rendering of these thin lines<br> <ydaniv> dbaron: another way of saying it is that the position where we draw things is [missed]<br> <ydaniv> ... the problem is that if there are 2 things that occur in multiple positions, you need the distance to be consistent<br> <ydaniv> ... otherwise snapping can happen at different subpixel positions<br> <emilio> q+<br> <Rossen3> ack emilio<br> <dbaron> s/is [missed]/is based on snapping each edge to device pixels<br> <ydaniv> emilio: wanted to propose a resolution, fine to do it at use value time, it's always nicer for these things<br> <ydaniv> fantasai: sounds reasonable<br> <kbabbitt> +1<br> <ydaniv> Rossen3: we have a proposal...<br> <ydaniv> jfkthame: so if we round done for text decor, is that what we want as well?<br> <oriol> So auto and from-font will also be snapped, right?<br> <ydaniv> emilio: for borders it creates overflow<br> <fantasai> yes<br> <ydaniv> dbaron: I agree we don't need that aspect here<br> <emilio> PROPOSED: Snap text-decoration-thickness as a border width (https://drafts.csswg.org/css-values-4/#snap-a-length-as-a-border-width) at used-value time<br> <ydaniv> fantasai: I think for text to look more thick [missed]<br> <ydaniv> Rossen3: objections?<br> <fantasai> snapping down is probably the right call here, too, since it will obfuscate the text less<br> <ydaniv> RESOLVED: Snap text-decoration-thickness as a border width (https://drafts.csswg.org/css-values-4/#snap-a-length-as-a-border-width) at used-value time<br> <lea> q+<br> <ydaniv> Rossen3: dbaron please open separate issue on grid alignment<br> <Rossen3> ack lea<br> <emilio> q+<br> <ydaniv> lea: not objecting, but concerned that CSS is the wrong place to worry about rasterization, why are underlines special?<br> <ydaniv> ... if it's so thin that it becomes invisible, so why are doing this at all? would like more ppl to look at it<br> <oriol> See https://github.com/servo/servo/issues/29668. We had to snap auto in Servo, or otherwise we got no underline<br> <ydaniv> ... have seen snapping to 2px problematic in other features<br> <ydaniv> dbaron: to the begining of CSS, if it had this wierd combo of doing some rendering in some things and not others<br> <Rossen3> ack dbaron<br> <ydaniv> ... without transforms we don't do antialias at edge of box<br> <ydaniv> ... when you do things like %s sizing you get blurry edges<br> <ydaniv> ... for things like borders we decided that boxes and layout stuff, we layout and snap the edges, but for borders we wanted consistent thickness<br> <Rossen3> ack emilio<br> <ydaniv> emilio: wanted to give shorted answer...<br> <fantasai> Nobody wants fuzzy lines, basically<br> <dbaron> s/some rendering/subpixel rendering/<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/12696#issuecomment-3638291149 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 10 December 2025 17:52:30 UTC