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

On Wed, Sep 3, 2014 at 7:27 AM, Arthur Barstow <art.barstow@gmail.com>
wrote:

> On 9/2/14 6:26 PM, Patrick H. Lauke wrote:
>
>> On 02/09/2014 19:21, Rick Byers wrote:
>>
>>> Ping, any thoughts?
>>>
>>> Adding public-touchevents as I suspect people there will have feedback
>>> on this idea.
>>>
>>
>> Very first impression: why derivedFromTouchEvent and not something more
>> generic, such as compatibilityEvent or similar, leaving the door open for
>> other types of "emulated" mouse events (as a result of, say, a kinect-style
>> control).
>>
>
I cover some options like that in the document.  Basically the question is
how to reliably handle the case where an event is redundant with multiple
other events.  Eg. on IE phone, a 'mousedown' may be both logically
redundant with a pointer event and a touch event.  We could have a more
general API that returned an array of event types, or a 'isRedundantWith'
API that let's you pass event types, but both introduce a bunch of
complexity that may not ultimately provide any value.  Perhaps the simplest
improvement would be making 'derivedFrom' return an object with multiple
possible properties, so you could write 'if (e.derivedFrom &&
e.derivedFrom.touchEvent)'. Anyway, I'd be happy with anything along these
lines.

FYI, this topic was discussed during the September 2 D3E call <
> http://www.w3.org/2014/09/02-webapps-minutes.html>


Thanks!  The correct link is:
http://www.w3.org/2014/09/03-webapps-minutes.html

One suggestion there was to use: "MouseEvent.isEmlated".  There are some
problems with that approach.  Should a mousedown event sent in IE desktop
set this (since the MouseEvent is sent only for compatibility with clients
that don't know about PointerEvents)?  If so then what about code that's
designed to be aware of touch events but not pointer events?  More
generally, what if some new event API is added in the future (maybe
DepthCameraEvent) - it can't safely set it's compatibility events to
"emulated" without breaking sites.  Ultimately I think the client code must
indicate somehow what types of events it supports, so "emulated" can be
interpreted appropriately for what else the client code knows about.  Also
a minor nit, I don't think we consider 'click' events sent from non-mouse
devices to be "emulated" but rather 'click' has become a higher-level
activation concept that can be triggered from various input devices, right?


> -AB
>
>
>
>
>> P
>>
>>  Rick
>>>
>>>
>>> On Wed, Aug 27, 2014 at 10:26 AM, Rick Byers <rbyers@chromium.org
>>> <mailto:rbyers@chromium.org>> wrote:
>>>
>>> Hi,
>>> Web developers have long struggled to reliably identify which mouse
>>> events are actually derived from touch events. Sites need to know
>>> this to avoid double handling (eg. on both a touchend and click
>>> event), and have often just ignored all mouse events on a browser
>>> that supports touch events - seriously breaking functionality on
>>> devices with both a mouse and touchscreen.
>>>
>>> We (blink team) have tried for over a year to address this problem
>>> through evangelism (eg. encouraging
>>> <http://www.html5rocks.com/en/mobile/touchandmouse/> calling
>>> <https://www.youtube.com/watch?v=DujfpXOKUp8> preventDefault on
>>> handled touch events to suppress the generated mouse events). The
>>> situation has improved, but it's still a major problem (eg. it's the
>>> reason we haven't yet been able to rationalize Chrome's support for
>>> TouchEvents
>>> <https://code.google.com/p/chromium/issues/detail?id=392584> across
>>> devices, and the reason the IE team says
>>> <http://lists.w3.org/Archives/Public/public-touchevents/
>>> 2014Jul/0025.html> they
>>> implement touch events only on phones, not laptops).
>>>
>>> I recognize now that avoiding
>>> <https://code.google.com/p/chromium/issues/detail?id=115475#c13>
>>> adding a new simple API for this was a *big mistake*. There are
>>> legitimate reasons why the available workarounds are inadequate. For
>>> example, you may want to suppress/ignore mouse events without
>>> disabling browser behavior like focusing, activating links, etc. Or
>>> some listeners may want to ignore certain mouse events whose
>>> handling is redundant with that for touch events without affecting
>>> other listeners (perhaps in other components written by other
>>> developers).
>>>
>>> After considering a number of more general alternatives
>>> <https://docs.google.com/a/chromium.org/document/d/1-
>>> ZUtS3knhJP4RbWC74fUZbNp6cbytG6Wen7hewdCtdo/edit#>,
>>> I'd like to propose a very simple and targeted *addition to
>>> MouseEvent:* *a boolean 'derivedFromTouchEvent' property*. Note
>>> that this intentionally says the event represents input that was
>>> already reported via some other event, NOT that the event represents
>>> input from a touchscreen device (eg. browsers on Android send touch
>>> events for mouse and stylus, not just touch input). With this we
>>> could encourage sites to trivially transform this common broken pattern:
>>>
>>> if (‘ontouchstart’ in window)
>>> document.addEventListener(‘touchstart’, doStuff);
>>> else
>>> document.addEventListener(‘mousedown’, doStuff);
>>>
>>>
>>> Into this:
>>>
>>> document.addEventListener(‘touchstart’, doStuff);
>>> document.addEventListener(‘mousedown’, function(e) {
>>> if (!e.derivedFromTouchEvent) doStuff(e);
>>> });
>>>
>>>
>>> This new API can be trivially polyfilled on browsers (like Safari)
>>> which never support mouse and touch input at the same time with just:
>>>
>>> if (!('derivedFromTouchEvent' in MouseEvent.prototype))
>>>
>>> MouseEvent.prototype.derivedFromTouchEvent = ‘ontouchstart’
>>> in window;
>>>
>>>
>>> See this document
>>> <https://docs.google.com/a/chromium.org/document/d/1-
>>> ZUtS3knhJP4RbWC74fUZbNp6cbytG6Wen7hewdCtdo/edit#>
>>> for more details and other alternative proposals.
>>>
>>> Thanks,
>>> Rick
>>>
>>>
>>>
>>
>>
>