W3C home > Mailing lists > Public > www-dom@w3.org > January to March 2015

Re: [DOM3Events] Identifying mouse events derived from touch events

From: Rick Byers <rbyers@chromium.org>
Date: Wed, 21 Jan 2015 23:09:26 -0500
Message-ID: <CAFUtAY_0ELmsao97Xituy9vT5poCRh+xJB_ax+jmEjSecgqd+w@mail.gmail.com>
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>
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

This archive was generated by hypermail 2.3.1 : Tuesday, 20 October 2015 10:46:23 UTC