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: Tue, 20 Jan 2015 10:31:02 -0500
Message-ID: <CAFUtAY83hzKcN2z3orBmm4EQRgjJR+cJ6OCeBSY=peztfcksYA@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 3:14 AM, Anne van Kesteren <annevk@annevk.nl> wrote:

> On Mon, Jan 19, 2015 at 8:35 PM, Rick Byers <rbyers@chromium.org> wrote:
> > Jacob proposed a more generic 'Event.firedFrom' API which can be used to
> > determine whether one event represents the same physical input as another
> > type of event.  I've written up a detailed proposal here.
> This API seems rather contrived. An event class is not in charge of
> dispatching another event. If it is, I would like to see the
> underlying model for these events that led to that conclusion.

I understand this doesn't fit naturally into the existing model.  The
problem here is that the existing model (of different input event types
being entirely independent with no explicit backwards compatibility story)
has failed developers in practice and lead to a big mess stalling the
evolution of the platform (we can't enable the TouchEvent API more broadly
due to the hacks developers have felt compelled to resort to).

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?

Any other suggestions for how to make progress on this problem?  In
chromium we've been considering a trivial bit to communicate this
information (possibly just abusing 'modifiers') for years but failed to
make progress.  For what's an important real-world problem with potentially
trivial solutions, it's already a huge shame how long it's been hung up on
issues of formality.

(As far as I can tell one major problem here still is that we have not
> defined the underlying model for mouse events et al. What task they
> are dispatched from, which come from distinct tasks, etc.)

That seems like it would be nice to define (though I'm sure getting
implementations to align without breaking compatibility will be quite a
challenge), but I'm not sure I see why it's a blocker for the underlying
problem here.  In practice, developers aren't impacted much whether the
various related events come from the same tasks or not.  They just want to
know when the mouse events they see are redundant with the touch events
they recently saw.

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.).

> --
> https://annevankesteren.nl/
Received on Tuesday, 20 January 2015 15:31:54 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:37:05 UTC