- From: Dean Jackson <dino@apple.com>
- Date: Tue, 27 Sep 2011 05:35:46 +1000
- To: Chris Marrin <cmarrin@apple.com>
- Cc: "www-style@w3.org list" <www-style@w3.org>
- Message-id: <EE80015A-31F6-41AD-B8F1-8D836DFDA649@apple.com>
On 27/09/2011, at 3:01 AM, Chris Marrin wrote: > > On Sep 22, 2011, at 4:37 PM, Dean Jackson wrote: > >> [I really should cross-post this to public-fx since they'll eventually take ownership of the transforms specs, but that hasn't happened yet] >> >> This came up in: https://bugs.webkit.org/show_bug.cgi?id=67695 >> >> Relevant spec at: http://dev.w3.org/csswg/css3-3d-transforms/#animation >> >> Currently the spec says that transform animations interpolate the parameter values for rotate, rotateX, rotateY and rotateZ. The function rotate3d was left out because it probably doesn't make sense to do that for rotate3d(1, 0, 0, 10deg) -> rotate3d(0, 1, 0, 10deg). But I propose we add another clause for the case where the first three parameters match. > > "match" can be tricky, given that the vector could be computed and slight rounding error could creep in. For instance, rotating from rotate3d(0.707, 0.707, 0, 0) to rotate3d(1, 1, 0, 540deg) probably won't work, even though the two vectors are parallel. Neither vector is normalized and the spec says they will be normalized before being used. I computed the normalized values on my calculator (which I think has more precision that a JSNumber) and the results differed by -2e-12. So do we spec some slop? That's a good point. Webkit doesn't normalize the values until it uses them, so I think we could at least know that identical inputs are the same number. I don't think we should compare post-normalized values. Dean
Received on Monday, 26 September 2011 19:36:32 UTC