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

I'm in favour of Patrick's idea of a generic name if we go down this route.
I would have expected it to have made the variable true in the event of a
developers callback existing but the compat event is still fired because of
no evt.preventDefault(). For IE if pointer event callback is used but
another event is called, then I'd deem it a compat callback.

I do still believe the main issue is how we can get out of these compat
scenarios altogether (I.e. stop firing them in the first place). If you
think of the web manifesto, surely the goal here is to create the
primitives that people can build on - in this case touch and mouse events
firing for touch or mouse respectively and no cross firing.

But I can't think of a scenario in the web where this has been achieved
without creating a completely new API.
On 3 Sep 2014 15:41, "Rick Byers" <rbyers@google.com> wrote:

> 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>
>>
>
>