- From: Dean Jackson via GitHub <sysbot+gh@w3.org>
- Date: Mon, 28 Jan 2019 23:40:46 +0000
- To: public-pointer-events@w3.org
> > What hardware? iOS certainly does not provide xTilt and yTilt. > The sensor hardware. Yes, but that's irrelevant. We don't provide the sensor data. We don't tell the app what the voltage measured in the sensor is, for example. The Web exposes APIs that make sense to developers, and in this case the Pointer Events specification provides the less useful information. > Even with an Apple pencil the touch sensor measures xTilt and yTilt. This highlights my point. Apple doesn't expose that to the developer. It exposes azimuth and altitude, because that makes more sense. > > Not all hardware uses an eight-bit micro and, even then, every event here is going through the browser engine, where the overhead from the trig function is going to be negligible compared to the event dispatch, the call into JavaScript, and then the processing JavaScript will do. This is premature optimization to the extreme. > Everything going thru the browser engine went thru the OS first, and the low level native API is usually xTilt, yTilt (Windows, Mac, and Linux). No. It seems to be tilt on Windows. Not on iOS. And again, the Web doesn't expose the low-level sensor data. It exposes a programming API. > > Again, since most apps will want azimuth and altitude, it makes more sense to serve those values and let the smaller number of apps that want tiltX and tiltY to calculate that as needed. > The Wacom Wintab API provides both and developers can choose. In this situation this would provide backward compatibility. I'm fine with exposing both. As I'm implementing it right now, I might just do it. -- GitHub Notification of comment by grorg Please view or discuss this issue at https://github.com/w3c/pointerevents/issues/274#issuecomment-458347176 using your GitHub account
Received on Monday, 28 January 2019 23:40:48 UTC