- From: jsnowranger via GitHub <sysbot+gh@w3.org>
- Date: Fri, 16 Aug 2024 14:31:45 +0000
- To: public-css-archive@w3.org
Thanks for the visual example! That's good to know. I think the best way to describe my question at this point, given what we've discussed so far, is: why wouldn't `border-width` support sub-pixels? Your example shows that sub-pixels can be rendered and have a visual impact on the layout. And even otherwise, there are uses for the information like for anti-aliasing. The [spec](https://drafts.csswg.org/css-values-4/#lengths) mentions: > While the exact supported precision of numeric values, and how they are rounded to match that precision, is generally [implementation-defined](https://infra.spec.whatwg.org/#implementation-defined), [<length>](https://drafts.csswg.org/css-values-4/#length-value)s in ***[border-width](https://drafts.csswg.org/css-backgrounds-3/#propdef-border-width) and a few other properties are rounded in a specific fashion to ensure reasonable visual display.*** In other words, since `border-width` is being rounded, every user agent should round it the same way. But why does `border-width` have to be rounded/snapped in the first place? Clip rects, overflow rects, scroll height and width, margin, padding, location, and size of rendered elements all use sub-pixels. `border-width` also contributes to the space taken up by an element, but it's snapped to a whole pixel. That's along the lines of what I meant when I mentioned consistency. What drawbacks would there be to supporting sub-pixels in `border-width`? -- GitHub Notification of comment by jsnowranger Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10729#issuecomment-2293621019 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 16 August 2024 14:31:46 UTC