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

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

From: Olli Pettay <olli@pettay.fi>
Date: Thu, 22 Jan 2015 14:34:26 +0200
Message-ID: <54C0EE52.6040604@pettay.fi>
To: Rick Byers <rbyers@chromium.org>, 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 01/22/2015 06:09 AM, Rick Byers wrote:
> On Tue, Jan 20, 2015 at 10:59 AM, Anne van Kesteren <annevk@annevk.nl <mailto:annevk@annevk.nl>> wrote:
>     On Tue, Jan 20, 2015 at 4:31 PM, Rick Byers <rbyers@chromium.org <mailto: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'.

In Gecko MouseEvents have the non-standard 'readonly attribute unsigned short mozInputSource;'

enum InputEventSource {
   "keyboard" // for 'enter' key event triggering 'click'
readonly attribute InputEventSource inputSource;

might work pretty well.

I wouldn't add derivedFromTouchEvent. That makes the APIs depend on each others too much, and given we probably want to expose
different derivedFrom values too, it would easily become very ugly.


>  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 12:34:53 UTC

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