- From: Rick Byers <rbyers@chromium.org>
- Date: Tue, 20 Jan 2015 10:31:02 -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: <CAFUtAY83hzKcN2z3orBmm4EQRgjJR+cJ6OCeBSY=peztfcksYA@mail.gmail.com>
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:49 UTC