Re: [csswg-drafts] [css] Proposition of new style for rounding border-widths, padding etc. (#2127)

So a few thoughts on opting in to an antialiasing behavior rather than pixel snapping:
* one thing that developers generally dislike about antialiasing (at least in the typical coverage-based implementation rather than supersampling, which is expensive in terms of memory use) is that two objects of the same color that are adjacent (have a common edge) do not produce a continuous area of that common color:  instead there is a seam because of the two separate polygons being drawn with antialiasing.
* It's also not clear from the proposal whether the "etc." includes raster images.  Does this proposal expect that in an antialiasing world, raster images that have a 1:1 scale with the device display, but are not device-pixel-aligned, will be blurred to match the antialiasing of adjacent pixels?  (If not, and they're snapped instead, you'll end up with the seams problem above, but even worse on one side of the image!)

Without a clear statement of the *use cases* that this feature is intended to solve, it's hard to know how problematic these things are, or what the intended behavior for raster images is.

(To @frivoal's comment:  I'm not sure how closely related this issue is to the fact that border widths are snapped differently from other things.  In general, the way we do pixel snapping is that we snap border widths (and text-decoration widths, and maybe line heights) to device pixels at value computation time, whereas other things remain subpixel values (fixed point fractions of a pixel, rounded down) during layout.  Then following layout we snap all *edges* (not sizes) to the nearest device pixel boundary.  This means that borders, text-decorations, and line heights stay uniform for all uses of the same value, rather than varying depending on their subpixel position.  But for other values it means that subpixel values add up in a way that never breaks layouts by taking too much space (since the subpixel values are rounded down rather than to nearest), and it means that it's very rare (since the values are fractions of a pixel rather than whole pixels) for a set of percentages that add to 100% to end up a pixel short and leave a visible gap at the edge of the box when something had been expected to fill a box.)

-- 
GitHub Notification of comment by dbaron
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/2127#issuecomment-1860571879 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Monday, 18 December 2023 13:58:10 UTC