Re: Phasing out mouse compatibility events on tap?

On 16/01/2015 23:03, Jacob Rossi wrote:

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

I don't think, at least looking at the thread starter, that this was 
ever about performance gain, but just about making life easier for devs.

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

I think the main win (though agree there's much overlap with firedFrom) 
would be that devs can keep their very mouse-specific handlers untouched 
(no need to add any extra test for "was this fired as result of a touch, 
as a compat event?") if they can be safe those handlers won't be called 
anyway since they explicitly suppress mouse compat.

Then again, they'd still need to (in most scenarios) de-dupe click, so 
this proposed way of suppressing mouse* events can only work 
hand-in-hand with firedFrom to cover all cases...

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 Saturday, 17 January 2015 00:04:09 UTC