RE: Phasing out mouse compatibility events on tap?

[Adding input-dev back]

I'm not sure I understand the value/premise. IE currently fires the Pointer Events model for compatibility mouse events but we've been experimenting with trying the more simplified Touch Events model for better interoperability (we'll probably expose this under a flag initially to see how it goes).  So this means our latest codebase handles Pointer Events, Touch Events, and also two models for Mouse Events (if we decide to ship the TE model, we'll probably delete the code for the PE model...but that's yet to be decided).

Yet, we don't see a performance hit if mouse events aren't being listened to. We cache hit-test results from Pointer/Touch events for use in the mouse events when they are in use (avoiding double hit-testing). If we added a CSS API for disabling mouse events on a node by node basis, then you still need to hit-test to determine which node to retrieve the value of that property...so how does that help perf? The data structure of a MouseEvent is extremely small and would be inconsequential memory savings to not have to create.  

Is there a developer win here* (assuming we also solve the firedFrom() scenario in another way)? If not, then I think adoption of some new "don't fire Mouse Events" API would be pretty low.

-Jacob

* It probably goes without saying, but I agree with the earlier comments in this thread that such an API might actually be a developer/user *loss* because it might encourage more touch-only sites.

-----Original Message-----
From: Patrick H. Lauke [mailto:redux@splintered.co.uk] 
Sent: Friday, January 16, 2015 1:57 PM
To: public-touchevents@w3.org
Subject: Re: Phasing out mouse compatibility events on tap?

On 16/01/2015 21:18, Rick Byers wrote:
> On Fri, Jan 16, 2015 at 4:04 PM, Patrick H. Lauke 
> <redux@splintered.co.uk <mailto:redux@splintered.co.uk>> wrote:

>     Only question is: as "click" is currently handled as a compatibility
>     event as well in the TE model, would the above also kill "click"?
>
>
> Why do you say click is handled as a compatibility event?

I was basing that on the behavior I observed following preventDefault...but fair enough, as TE doesn't currently define what is and isn't a compat event, this was purely my gut assumption.

>  I consider TE
> to be pretty similar to PE in the regard that "mouse*" events are for 
> compat, but "click" supplies real semantics / value outside of compat

Oh, I agree. Again, was basing this - erroneously perhaps - on my observation of what happens when you preventDefault.

>     var clickEvent =  ('ontouchstart' in window ? 'touchend' : 'click');
>     blah.addEventListener(__clickEvent, function() { ... }, false);
>
>
> Whoa - detecting a 'tap' is more involved than that in practice. You 
> don't want your 'click' function to fire for every swipe, or fire 
> multiple times after a multi-touch, right?

This code isn't mine, and it's simplified, but mirror stuff I've actually seen used in practice in the wild as a "performance trick" to remove the 300ms back in the day.

Ok, so if this proposal is purely about suppressing the various mouseover > mousemove > mousedown > mouseup compat event sequences, then it won't help with the above naive 300ms circumvention I've seen. What use cases are you thinking of then? Things like dropdowns/panels appearing on mouseover (as we can then programmatically suppress that mouseover compat from being fired, so any incoming mouseover is guaranteed to be from an actual mouse)? If so, I'd still tend toward method on event :) (and I guess the "don't fire twice...once for touchend, once for click" type scenario can be disambiguated with the other proposed way of signalling that the click was derived from a touch action).

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

Received on Friday, 16 January 2015 23:03:51 UTC