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

On 01/22/2015 06:21 PM, Olli Pettay wrote:
> 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?
I mean, if we add inputSource also to TouchEvents/PointerEvents, then it is up to the application logic to decide what to do with the events.


>
>
>>
>> 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:27:00 UTC