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

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

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

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

Received on Wednesday, 3 September 2014 11:28:13 UTC