[css] Proposition of new style for rounding border-widths, padding etc.

[Nadya678]

I propose:

renderer: aliased | antialiased;

if developer will want to work with subpixels, he/she can enable renderer:antialiased and borders, width etc. will be rendered with antialiasing.

How about this solution?

For aliasing mode there shall be in future defined one algorithm or added new values for "renderer" defining bahaviours from FF, IE and Cr.

[SebastianZ]

I propose:

renderer: aliased | antialiased;

if developer will want to work with subpixels, he/she can enable renderer:antialiased and borders, width etc. will be rendered with antialiasing.

How about this solution?

What's the use case for this proposal? Note that there are already text-rendering and image-rendering to improve speed or visual optimization.

For aliasing mode there shall be in future defined one algorithm or added new values for "renderer" defining bahaviours from FF, IE and Cr.

It would surely be enough to have one value for aliasing mode.

Two general notes:
IE is dead. You mean Edge.
Keep in mind that user agents interpreting CSS are not restricted to web browsers, and not just those three.

Sebastian

[Nadya678]

Use case: what shall be rendered: border-width:1.5px? border-width:0.1px?
Please test the IE, Chrome and Firefox
There is needed unification. On retina screens this can be rendered with sub-pixels but on the standard PC in part of cases the antialiased renfering will be proper solution.

The 1.5px value doesn't have to be defined explicitly but relatively by use of rem unit.

[SebastianZ]

Use case: what shall be rendered: border-width:1.5px? border-width:0.1px?

That's a question asking what to do in those cases, not a use case for your "renderer" property.
CSS Cascading and Inheritance spec. says it's up to the user agent what to do with values that can't be displayed in the given environment and uses exactly the example of border widths as an example:

A used value is in principle ready to be used, but a user agent may not be able to make use of the value in a given environment. For example, a user agent may only be able to render borders with integer pixel widths and may therefore have to approximate the used width.

Though according to your description, your use case is to give authors a way to unify the rendering across user agents in those cases.

Personally, I think rather than introducing a new property the spec. should 1) define that user agents should use antialiasing in those cases and 2) clarify how values should be rounded when user agents don't support antialiasing.

Sebastian

[Nadya678]

@SebastianZ Big + for antialiasing. Also please do not forget about retina screens (3x3 physical pixels for one CSS px).

I think there should be defined a style to enable/disable antialiasing if it is supported.

I use on part of HTML/CSS applications definition:

html
{
   font-size:1px;
}
body
{
   font-size:1600%; /* the 16rem is wrongly switched in Cr during resizing the window */ 
   border:0;
   margin:0;
}
any-element
{
   border:...rem;
   margin:...rem;
   etc. etc. 
}

and...

@media screen and (max-width:400px)
{
   font-size:0.75px; /* full zoom effect */
}
@media screen and (max-height:400px)
{
   font-size:0.75px; /* full zoom effect */
}
@media screen and (max-width:250px)
{
   font-size:0.5px; /* full zoom effect */
}
@media screen and (max-height:250px)
{
   font-size:0.5px; /* full zoom effect */
}

But the not-defined border-width (and margin, padding...) rounding makes problem. Thus the antialiasing or defined rounding behaviour is needed to be defined for example for small devices.

The application can be used on very small screens like smart-watches.

[kizu]

I'd want to bump this issue.

Just today I had a bug at work where there was a significant difference between Safari and Chrome resulting in a significant visual difference between elements due to the absent interoperability of subpixel values.

• I did mention this in Mastodon today: https://front-end.social/@kizu/111585513495742346 (after which I did find this issue).
• I did found a post by @huijing who did bring this issue up in 2019: https://chenhuijing.com/blog/about-subpixel-rendering-in-browsers/
• In her post, she mentions a post by @jeresig from 2008: https://johnresig.com/blog/sub-pixel-problems-in-css/

Subpixel interop is something I constantly stumble upon in practice. Currently, we have to use preprocessors for rounding things.

With round() we will be able to apply fixes more reliably, but it won't change the status quo, where unless you'll explicitly opt in to using round() for every place that requires it, things might look different and result in bugs.

Having some way to control this on a scale will be great.

[frivoal]

cc @dbaron: I seem to remember you talking about the non trivial amount of thinking that went into trying to do something sensible when rounding sub-pixel borders and the like. Any thoughts on this issue?

[dbaron]

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.)