Re: [DOM3Events] InputDevice API sketch

Hi Rick (and all the others, too ^_^),

Sorry for taking a week to reply, I really needed that time to put my thoughts in order and write them down :D 


I was very glad to see some work being done in order to define the Input Device drivers of the web, and I wanted to share my vision with you on the matter. Like you, I believe that Pointer Events require some more metadata (coarsity, drag inertia, …) on the devices generating the events to be able to handle new types of inputs properly and I'm a huge fan of your proposal. My free time is overbooked but if some working group discussed this further I would be happy to participate in refining your proposal.


Yet, I believe there's some important challenge it doesn't tackle. Something I don't like in general about Input Devices at this time is how "customized" any good device handling has to be, and how native apps often have to rely on device-specific userland drivers to harness the true device capabilities (those are not available to the web). I argue the reason of this issue is the lack of a sufficiently generic class of devices which could encompass multiple sensors and ways to interpret them, providing each app with the pieces of info it want with the granularity it needs; to sum up, I think we lack a metamodel unifying even more input devices than ever before.


Let's be honest, I think the proposal I'm going to make is probably far away from how most input devices are handled at the OS level at the time I write it. As a result, I'm conscient an initial implementation of the proposal will have to mock the features using the native input events of the existing platforms (a clear con). I would argue (though) that it is the case of currently implemented APIs like the Gamepad API and the PointerLock specification, from which this proposal draws ideas from.


However, I think the API I propose is promising and has some interesting features; though I'll of course let you be your own judge on that matter ;-) I've put toegether my ideas in a draft document [1] and an API surface [2]. 


[1] https://docs.google.com/document/d/1Ubgn0uZ73DGkBnEPKJ5CfSk-YPu5MDjq_We1gy1kFEg/edit?usp=sharing

[2] https://gist.github.com/FremyCompany/a70ee6a02d54c3d9521d



I would be interested to hear about what you guys think about this proposal, because I can't make this happen without you! Please feel free to comment on the Google Doc, on the Gist or by email. Please make me happy: my main intent is to initiate a discussion :-)


Best regards,
François


_________________

PS:


Please note that for the purpose of this exercice, I included devices ranging from Webcams to Touchscreens (via Depth-cams and Smart pens with gyros; but *not* next gen devices like the Leap Motion or the Kinect Skeleton Tracking, as I don't have enough experience with such devices). However I worked on cutting-edge and amazing input device scenarios like using the Mac's touchpad as a multitouch input [1], a Microsoft Touch Mouse [2], or a calibrated webcam/dephtcam [3].


[1] http://notebooks.com/2011/08/10/touchgrind-brings-multitouch-gaming-to-the-mac/

[2] http://www.hanselman.com/blog/AbusingTheMicrosoftResearchsTouchMouseSensorAPISDKWithAConsolebasedHeatmap.aspx

[3] https://youtu.be/YXJ9dmxsc6w







De : Rick Byers
Envoyé : ‎lundi‎ ‎9‎ ‎mars‎ ‎2015 ‎16‎:‎07
À : DOM WG, Gary Kacmarcik (Кошмарчик), Domenic Denicola, Mustaq Ahmed





In our latest discussion of how best to identify mouse events derived from touch events, I proposed a 'sourceDevice' property.  Domenic asked for a rough sketch of what such an InputDevice API might grow to become.  Here is my first attempt at such a sketch, including some detailed references to similar APIs in other platforms.  Any thoughts?



Note that at the moment I'm primarily interested in standardizing and implementing the 'firesTouchEvents' bit.  However if it makes more sense for coherency, I'd also support adding (and implementing in chromium) a few of the other non-controversial pieces.




Rick