- From: Rick Byers <rbyers@chromium.org>
- Date: Wed, 21 Jan 2015 23:09:26 -0500
- To: Anne van Kesteren <annevk@annevk.nl>
- Cc: "www-dom@w3.org" <www-dom@w3.org>, "public-touchevents@w3.org" <public-touchevents@w3.org>, Jacob Rossi <Jacob.Rossi@microsoft.com>, Mustaq Ahmed <mustaq@chromium.org>
- Message-ID: <CAFUtAY_0ELmsao97Xituy9vT5poCRh+xJB_ax+jmEjSecgqd+w@mail.gmail.com>
On Tue, Jan 20, 2015 at 10:59 AM, Anne van Kesteren <annevk@annevk.nl> wrote: > On Tue, Jan 20, 2015 at 4:31 PM, Rick Byers <rbyers@chromium.org> wrote: > > Is my earlier proposal (a single "derivedFromTouchEvent" bool on Mouse > > events) preferable in your opinion? Or does it just suffer from the > exact > > same problem? > > I think that might be better as it is more scoped. Since we don't > really understand this space much from a theoretical perspective I > would be hesitant to add generic APIs. > Understood, thanks. Jacob, you are the strongest proponent for the 'firedFrom' model over the 'derivedFromTouchEvent' one. Any thoughts? Here's a 3rd option we haven't discussed in detail yet: What if input events all had a 'sourceDevice' attribute which returned an object with an attribute like 'firesTouchEvents'. I've argued that the problem here is NOT one of source device but of related events, but if the source device says explicitly what event types it fires and developers test that (rather than inferring it from some "device class") then that's just as good. In the pointer events working group we had other reasons to want an input device API (eg. 'navigator' is really a poor place for 'maxTouchPoints'). Perhaps this is as good as a reason as any to start exposing an input device properties object. I wouldn't argue here for hanging a bunch of extra stuff of it, but it's reasonable to think that over time we'll want an API surface like this. Most other platforms have such a facility (eg. MotionEvent.getDevice <http://developer.android.com/reference/android/view/InputEvent.html#getDevice()>() on Android). As your document suggests it is unclear what to include. Which also > suggests it does not fall out automatically from some underlying > primitive. Rather, we do this in various places as localized hacks and > there is probably not a generic framework that encompasses them well. > Yes, I agree this is a good legitimate argument against this design. > > That said, if this group is interested in trying to spec this out in > detail, > > I'm happy to help from the chromium side (explaining our implementation, > > trying to tweak it to align with the model you all agree on, etc.). > > I've been trying to get the people defining UI Events to do this for a > while now without much success. > > > -- > https://annevankesteren.nl/ >
Received on Thursday, 22 January 2015 04:10:14 UTC