Re: [w3c/gamepad] Added GamepadPose and GamepadCapabilities (#25)

Thanks for the feedback, Domenic!

In a previous version of WebVR (which this proposal is based on) we did use DOMPoints, but when we refactored we switched to using TypedArrays because it wasn't clear that the Geometry spec was actually making progress. There seemed to be a lot of debate in the mailing lists about the actual benefit of the matrix type specifically and there didn't appear to be active development or spec work happening. As such we were loath to gate our spec behind one with an apparently uncertain future. In fact, looking at https://www.chromestatus.com/features/6015941766807552 it seems that the situation is still the same on the Chrome side of things. It's listed as "No Active Development" and just today the shipping bug has someone asking about release timelines after half a year of inactivity.

If you have further insight into the status of the Geometry interfaces I'd love to hear!

Beyond that I disagree with some of the other points. The TypedArrays don't show up as cleanly in an inspector window, but there [are libraries](http://glmatrix.net) that make using them as easy as any other explicit vector type. Possibly faster, too, as one of the criticisms leveled at the Geometry interfaces was that the marshaling required to get the values into native code would negate the benefits of doing the operations natively.

It's also unlikely that most code bases will use the type provided directly no matter what we provide, as almost all 3D or other game libraries have their own concept of vector that this would need to be converted in and out of. In Three.js, for example, can convert from either an object with x/y/z/w members or an array with equal ease.

I'm also a bit concerned by DOMPoint not distinguishing between 3 and 4 element vectors, and by representing a Quaternion with a type named "Point". In either case the user will have to refer to the spec to understand the meaning of the attributes, but a generic array seems less potentially misleading.

As for the mutability argument, I do admit it's a concern. I've heard it suggested that the array properties should be marked up as [Frozen], which seems reasonable to me, but I sadly my WebIDL knowledge fails me here and I'm not sure how to properly express that in the spec. Pointers welcome!

I'm not completely against using a more explicit type for these values, but hopefully I've adequately explained why this proposal does not rely on DOMPoint. I'm happy to discuss further, as I'm sure I'm not as intimately familiar with the state of that API as some. 

---
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/gamepad/pull/25#issuecomment-235773504