albell
commented
10 years ago Browsers generally optimize for this stuff during layout. E.g. a value of 5.55px will typically be rounded to 6px. That extra half pixel from the rounding is arguably the correct behavior. If you've set your CSS colors and layout sensibly it shouldn't be a visual problem. Percentage-based layouts always encounter funny rounding errors here and there. That's simply in the nature of the math. When dividing an odd number by an even number, there's always a remainder to get stuck somewhere. Rounding in javascript (the page) instead of rounding in C++ (the browser) won't solve the fundamental problem. Webkit/Blink both have subpixel rendering for the past couple years:
http://trac.webkit.org/changeset/116009
The pixel-snapping happens at the very end of layout, which solves lots of layout bugs. Browsers all do it a bit differently, which can definitely be annoying.
But keep in mind also that at least on some browsers, retina displays will render out half a CSS pixel as a single hardware pixel. For example, in current Firefox you can write:
border: 0.5px solid black;and on a retina screen it will render out as one hardware pixel. FF FTW! AFAIK Webkit doesn't have this yet, but I'm gonna go ahead and guess that both will before too long. See:
http://atirip.com/2013/09/22/yes-we-can-do-fraction-of-a-pixel/
So sub-pixel CSS values aren't meaningless, in fact they're likely to become more common as display densities increase. The CSS integers-only approach would limit layouts to whole CSS pixels, so I'm not sure this change is a good idea.
Can you post a fiddle showing this as a bug? What you expect vs. what you get, and how this change would solve it?
Sub-pixel heights when using the autoheight ratio, can show a pixel offset when you set a background color on the slider.
In my projects I add Math.round() around the height calc, it'd be nice if it were added to the plugin, unless there is a reason not to.
https://github.com/malsup/cycle2/blob/master/src/jquery.cycle2.autoheight.js#L59-L62