-
Notifications
You must be signed in to change notification settings - Fork 645
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[css] Proposition of new style for rounding border-widths, padding etc. #2127
Comments
What's the use case for this proposal? Note that there are already
It would surely be enough to have one value for aliasing mode. Two general notes: Sebastian |
Use case: what shall be rendered: border-width:1.5px? border-width:0.1px? The 1.5px value doesn't have to be defined explicitly but relatively by use of rem unit. |
That's a question asking what to do in those cases, not a use case for your "
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 |
@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:
and...
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. |
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.
Subpixel interop is something I constantly stumble upon in practice. Currently, we have to use preprocessors for rounding things. With Having some way to control this on a scale will be great. |
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? |
So a few thoughts on opting in to an antialiasing behavior rather than pixel snapping:
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.) |
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.
The text was updated successfully, but these errors were encountered: