30238 2009-10-08 16:41:48 -0700 getComputedStyle-transform.html accidentally relies on float formatting details 2009-10-14 14:55:22 -0700 1 1 1 Unclassified WebKit CSS 528+ (Nightly build) PC OS X 10.5 RESOLVED FIXED P2 Normal --- 18994 1 evan webkit-unassigned darin simon.fraser oldest_to_newest 153565 0 evan 2009-10-08 16:41:48 -0700 Relevant code: // set one of our test transforms testBox.style.webkitTransform = curTest.transform; // read back computed style var oldTransform = window.getComputedStyle(testBox).webkitTransform; // set that matrix() back on the element testBox.style.webkitTransform = oldTransform; // read back computed style var computedTransform = window.getComputedStyle(testBox).webkitTransform; Suppose the following. In step 1, when when we apply the transform one of the elements of the underlying matrix ends up being 0.23000005. In step 2, when we read it back as a string, WebKit passes it through a printf(), which prints it to 6 significant digits as "0.230000". In step 3, when we write it out again, that that string is parsed into the float 0.23. In step 4, when it's read out again, it's now the string "0.23". I ran into this in fixing float handling. I'd like to remove the second two lines of the above code (the test input has a string for the expected output). What do you think? 153567 1 simon.fraser 2009-10-08 16:45:11 -0700 I think the test should stay the same, but we should round when printing the output and comparing with the expected values. 153570 2 evan 2009-10-08 16:59:15 -0700 The strings in question look like "matrix(1, 0.36397, -0.842288, 1, 0, 0)" So are you suggesting parsing those strings into separate fields? Or can I read each field of the matrix as a float in js code, like by doing domnode.webKitTransform.<something here>? 153572 3 evan 2009-10-08 17:05:41 -0700 Oh, I think I found a better option: printf is actually specified to have this behavior (where trailing significant digits are chopped if they are 0). I think I can hack my float-printer to emulate it. 153573 4 evan 2009-10-08 17:06:49 -0700 (I still think the test is kinda wrong for the reason I mentioned though.)