- From: Rick Byers <rbyers@chromium.org>
- Date: Fri, 16 Jan 2015 10:51:50 -0500
- To: Matt Gaunt <mattgaunt@chromium.org>
- Cc: input-dev <input-dev@chromium.org>, "public-touchevents@w3.org" <public-touchevents@w3.org>
- Message-ID: <CAFUtAY8ANH04BBuKjHix5T2SFmhV0cyTH6zM+sFBnCEwJyAc0A@mail.gmail.com>
[Context: Matt raised a good <https://docs.google.com/a/chromium.org/document/d/1-ZUtS3knhJP4RbWC74fUZbNp6cbytG6Wen7hewdCtdo/edit#heading=h.rbcct8al2kop> point in my 'identifying mouse events derived from touch' document that the compatibility mouse events we send on tap may be causing more confusion than benefit.] I don't think we want to try to phase out sending 'click' on tap (since 'click' really means 'activate' - eg. used for the enter key also), and so still need a way to identify which click events are derived from touch events. But there really is no good reason to be firing mousemove, mouseover, mouseenter, mousedown, and mouseup for every tap outside of legacy. At a minimum they add a bunch of extra overhead and complexity (especially since we typically need to do a hit-test after each) and provide absolutely no value to a modern touch-optimized web experience. But worse, I think they add conceptual complexity and confusion. I believe lots of websites still rely on these events for compat, but we should start thinking about how we could phase them out. Eg. maybe we should define an API to enable/disable them and work towards making disabling the default - at least in modern scenarios? We could pretty easily get some experience with this now - eg. a flag in chromium which disables the mouse* events on tap for sites we identify as not needing "desktop workarounds" (i.e. based on the viewport)? Matt, would doing something like this address your concern? input-dev, WDYT - should we try to do some implementation experimentation in chromium here? TECG, do you think this is a problem worth tackling / potentially designing an API for? Rick
Received on Friday, 16 January 2015 15:52:44 UTC