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

On 01/22/2015 05:55 PM, Rick Byers wrote:
> On Thu, Jan 22, 2015 at 7:34 AM, Olli Pettay <olli@pettay.fi <mailto:olli@pettay.fi>> wrote:
>
>     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> <mailto: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> <mailto: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;'
>     and the value can be MOZ_SOURCE_UNKNOWN, MOZ_SOURCE_MOUSE, MOZ_SOURCE_PEN etc.
>
>     enum InputEventSource {
>        "",
>        "touch",
>        "mouse"
>        "pen",
>        "keyboard" // for 'enter' key event triggering 'click'
>     };
>     readonly attribute InputEventSource inputSource;
>
>     might work pretty well.
>
>
> Just exposing the type of source device is insufficient.  Eg. in IE desktop the source device is touch, but since it didn't generate any touch events
> the logic shouldn't assume touch event handlers have run.

We shouldn't use this thing for feature detection. If touch events aren't supported, they aren't.
But the source can still be touch.
For feature detection, ("TouchEvent" in window) should work.


> Conversely Firefox for Android fires touch events for a mouse, so even though the actual
> source device was a mouse, app logic should still expect the mouse events to be redundant with touch events.
Why, if also mouse events are fired?


>
> So we need some indication about the relationship between events types.  But doing this via some InputDevice object seems like good step forward along
> a path we wanted to go down anyway.
>
>     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.
>
>
>
>     -Olli
>
>           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()
>         <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 16:21:47 UTC