Bugzilla – Bug 15709
Constraints need to be placed on rounding for testability
Last modified: 2012-05-09 14:32:45 UTC
In my transforms test suites, I have to do things like check that getComputedStyle() and getBoundingClientRect() are correct. Some rounding error is to be expected, since this is floating-point. But the spec doesn't say how much is allowed, which makes it impossible to say how much tolerance my tests should give. The tolerances I currently use in my tests are
* getBoundingClientRect() must always return box offsets within 1.5px of the values that would be produced by doing all operations with perfect precision.
* getComputedStyle().transform must have all matrix entries within 0.05 of the exact specified values, after precise matrix multiplication if multiple transforms are given.
* getComputedStyle().transformOrigin, .perspective, and .perspectiveOrigin must have all values within 0.05px of the exact specified values.
These tolerances might be infeasibly tight in some cases -- particularly the first. Arbitrarily small errors in evaluating a transform matrix can add up to arbitrarily large errors in the positions of boxes, particularly far away from the origin. Perhaps the first should be loosened to say that it has to be within some small amount (maybe 0.5px to allow rounding to whole pixels) of the values that would be produced if the exact values returned by getComputedStyle() were used.
Currently some browsers round too much, for sure. Gecko and Opera both round computed values such that you can easily create a transform that's mathematically the identity but offsets everything by 1000px (or whatever) -- <https://bugzilla.mozilla.org/show_bug.cgi?id=719173>. WebKit rounds to whole pixel values in a bunch of places, like the computed style of transform-origin, which could easily add up to multi-pixel errors. It should be possible to make them fail test cases for this and be able to point to something in the spec to justify it.
How should the CSS Transforms spec address these issues? It looks more like a issues on implementations.
I guess we don't have to explicitly address it, as long as we're okay with tests using ad hoc precision requirements.
Moving to Values and Units per discussion at the Hamburg F2F.