Re: Phasing out mouse compatibility events on tap?

Do you dispatch mouse events for websites that do not register any mouse
event listener (are there such websites? I mean, ones that only register
touch events)?
By "dispatch", I mean, exercise the overhead and code path for hit testing.


☆*PhistucK*

On Fri, Jan 16, 2015 at 5:51 PM, Rick Byers <rbyers@chromium.org> wrote:

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