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

On Tue, Sep 2, 2014 at 7:26 PM, Arthur Stolyar <nekr.fabula@gmail.com>
wrote:

> It would be good to have js property on DOM node or css property if it's
> better which can disable compatibility events, e.g.
>
> element.compatibilityMouseEvents = false;
>

One of the main problems I'm trying to solve here is that JS components are
reluctant to call preventDefault on TouchEvents because of the potential
impact on other components.  Really the code wants to affect it's own event
handling logic without affecting the logic of anyone else that may be
watching the events.  So I don't think having an explicit properly to
enable/disable the compatibility mouse events will really solve the problem.

By the way, as I know touch-action with 'none' value disables delay on
> click events. Can we consider ability of touch-action to disable
> compatibility events? E.g. if developer uses any value other than auto,
> compatibility events are not sent to that region.
>
> I do not any case where developer need both touch and compatibility
> events. One possible case if third-party widgets, but for those widgets
> tocuh-action might be set back to auto to enable compatibility mouse events.
>

>
> 2014-09-03 1:26 GMT+03:00 Patrick H. Lauke <redux@splintered.co.uk>:
>
> 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).
>>
>> 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
>>>
>>>
>>>
>>
>> --
>> Patrick H. Lauke
>>
>> www.splintered.co.uk | https://github.com/patrickhlauke
>> http://flickr.com/photos/redux/ | http://redux.deviantart.com
>> twitter: @patrick_h_lauke | skype: patrick_h_lauke
>>
>>
>
>
> --
> @nekrtemplar <https://twitter.com/nekrtemplar>
>