This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 15709 - Constraints need to be placed on rounding for testability
Summary: Constraints need to be placed on rounding for testability
Status: NEW
Alias: None
Product: CSS
Classification: Unclassified
Component: Values and Units (show other bugs)
Version: unspecified
Hardware: All All
: P2 normal
Target Milestone: ---
Assignee: Tab Atkins Jr.
QA Contact: public-css-bugzilla
Depends on:
Reported: 2012-01-25 17:54 UTC by Aryeh Gregor
Modified: 2012-05-09 14:32 UTC (History)
8 users (show)

See Also:


Description Aryeh Gregor 2012-01-25 17:54:19 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) -- <>.  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.
Comment 1 Dirk Schulze 2012-04-26 05:51:55 UTC
How should the CSS Transforms spec address these issues? It looks more like a issues on implementations.
Comment 2 Aryeh Gregor 2012-04-30 05:51:19 UTC
I guess we don't have to explicitly address it, as long as we're okay with tests using ad hoc precision requirements.
Comment 3 Edward O'Connor 2012-05-09 14:32:45 UTC
Moving to Values and Units per discussion at the Hamburg F2F.