Re: Phasing out mouse compatibility events on tap?

On Sun, Jan 18, 2015 at 6:35 AM, Olli Pettay <olli@pettay.fi> wrote:

> 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).
>

I'm with Olli on this one. Also, with some browsers implementing the
changed model and some not (I can't see Safari or Presto changing at this
point), I can't see how this would make life significantly easier for
content authors.

-- 
Sangwhan Moon [Opera Software ASA]
Software Engineer | Tokyo, Japan