- From: Robert Kroeger <rjkroege@google.com>
- Date: Tue, 2 Sep 2014 14:17:13 -0700
- To: Rick Byers <rbyers@chromium.org>
- Cc: "www-dom@w3.org" <www-dom@w3.org>, input-dev <input-dev@chromium.org>
- Message-ID: <CA+erk4YyKwL4qHoB1_ih7KcT3n0c7q4-0q5LzT22U0fHNa7U0Q@mail.gmail.com>
On Tue, Sep 2, 2014 at 12:19 PM, Rick Byers <rbyers@chromium.org> wrote: > On Tue, Sep 2, 2014 at 3:01 PM, Robert Kroeger <rjkroege@google.com> > wrote: > >> >> On Wed, Aug 27, 2014 at 7:26 AM, Rick Byers <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). >>> >> >> I think this is a good choice for letting a site determine if the mouse >> events are derived from touch input. >> >> Is it worth considering one possible extension: given a derived event, is >> it worth letting the UA specify to the site what was the origin of the >> event? >> > > Thanks Rob. What sort of "origin"s were you imagining here? Do you mean > just other possibilities than just "from touch" (eg. 'click' events can be > 'derived' from keyboard input)? Or do you mean for the derived-from-touch > case, more details on the original action like "derived from a tap gesture"? > I was trying to anticipate future UAs deriving standard mouse / click events from gestures coming from still unusual devices like the Thalmic labs arm band. The site might want to take special action in such a context. > > 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:36:41 UTC