Re: Phasing out mouse compatibility events on tap?

On 01/16/2015 06:14 PM, Rick Byers wrote:
> On Fri, Jan 16, 2015 at 11:01 AM, Patrick H. Lauke <redux@splintered.co.uk <mailto: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?".

Not sure what this has to do with responsive web apps. The compatibility events aren't' dispatched often and shouldn't cause any real world 
performance issues (you need to do hit testing for click anyway, and in the most common case you could just cache the hit testing result and use that 
for all the events).

I'm not a fan of changing this already odd model to even more strange when in some mode some events are dispatched but in some other mode they aren't
- without seeing some data that adding the new mode has significant help in UX of web pages (and this after making sure browser engines don't do silly 
things with hit testing).


-Olli

>
>           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 <http://www.splintered.co.uk> | https://github.com/__patrickhlauke <https://github.com/patrickhlauke>
>     http://flickr.com/photos/__redux/ <http://flickr.com/photos/redux/> | http://redux.deviantart.com
>     twitter: @patrick_h_lauke | skype: patrick_h_lauke
>
>

Received on Saturday, 17 January 2015 21:36:25 UTC