Re: Phasing out mouse compatibility events on tap?

On Fri, Jan 16, 2015 at 11:01 AM, Patrick H. Lauke <redux@splintered.co.uk>
wrote:

> Quickfire gut reaction (beyond "dammit, do you want to remove all
> interesting topics from my presentation/workshop?")


Heh heh - I guess it's kinda the point of  the TECG to make input handling
so easy/obvious that it puts you out of a job <grin>.

On 16/01/2015 15:51, Rick Byers wrote:
>
>> I believe lots of websites still rely on these events for compat,
>>
>
> Which I believe is their entire "raison d'etre"...I'm sure it was a
> pragmatic solution taken by Apple at the time.


Absolutely.

 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?
>>
>
> Two issues:
>
> - the events are there for compat with "legacy" content...which is usually
> unlikely to be updated now. So default should be to have the compat events
> still enabled by default, no?
>

Yes, we can't go breaking the web.  But we might be able to identify some
subset where we could disable these events by default with little/no
negative impact, but I guess that's unlikely.  It can be useful to try some
(non-shipping-by-default) experiments though to help us learn about the
patterns of dependence here.  Eg. I'd hope that the vast majority of sites
with mobile viewports aren't relying on these today (but even then it's
probably not anywhere near the ~99.98% of page views we'd likely need to
even consider making this the default).

- how do you programmatically define/recognise (with heuristics) a "modern
> scenario"? I'd be weary of automagic behavior here. Also, there may be
> scenarios where even modern (recently built) sites somehow make use of
> mouse compat events (don't ask me why...) somehow (even if just to simplify
> their handling of stuff, e.g. setting a flag on touch* event, but leaving
> the actual functionality to happen on mouse* event).
>
> Perhaps looking on load if any mouse listeners have been registered may be
> an initial approach (though it would fall foul of any listeners that are
> dynamically added at a later date).


Yeah this is hard and probably impossible to come up with something we
could actually ship to people.  I don't think we should use presence of
handlers as a signal - that can result in 'heisenbugs' where the act of
adding an event handler changes the behavior of what you're trying to
observe :-(

So for now I think the most productive discussion is "in the long-run, do
we think you should be able to write responsive web apps that don't fire
these events, and if so what might an API to opt-out of them look like?".

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