- From: Robert Eisele via GitHub <sysbot+gh@w3.org>
- Date: Mon, 28 Aug 2023 21:57:33 +0000
- To: public-css-archive@w3.org
The reason I'm bringing this up is not the spherical interpolation part. As you said, it is already handled in the spec. And don't worry about the pushback. I think there was this study from MIT which compared classical brain-storming methods against how Linux kernel hackers push back new ideas. This way people who brought up new ideas always have to find new arguments to justify something new, which in the end brings much more quality into products. Anyway, I think the `quat()`/`quaternion()` extension has the highest value as a raw interface to rotations, not to tinker around with it manually. I think it's not just syntactic sugar, since Euler angles for example have the problem of gimbal locks (that you can rotate two axes in such a way that the third angle doesn't have any effect anymore). Since more and more APIs adapting quaternions, such as WebXR and I think there are discussions to get `devicemotion`/`deviceorientation` event data also as quat, it would be a natural extension to pass the data directly to CSS. As an overview: - `rotate3d()`: Is the closest you can get to quaternions at the moment. Converting a given quaternion would require some math knowledge - `rotateZ()rotateX()rotateY()`: Introduces gimbal locks and you need to make the order right - `matrix3d()`: Is already a raw interface to the whole transform. In practice it adds a lot of code to the user-space to build the matrix. To me, the `quaternion()` sits between `rotate3d()` and `matrix3d()` where you only pass 4 numbers and open the gates to other APIs. -- GitHub Notification of comment by infusion Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9243#issuecomment-1696483339 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 28 August 2023 21:57:35 UTC