These compatibility events can be considered as the 'legacy Pointer Events'. You can rely on them instead of registering events for every pointer inputs. While these can be a problem when you do implement event registration for every pointer input, this is (unfortunately? fortunately? I am not sure) atypical. The short term way of improving this would be to add a property on compatibility mouse events that regards them as simulated and the long term of improving this would be Pointer Events. I think adding this developer toggler would be bad for two reasons - - It encourages touch (or specific input) only implementations (you get better performance if you disable compatibility mouse events and your *primary* audience is smartphones with touch screens, so this is enough. The hell with the rest). - It can interfere with third party scripts you may add (even analytical ones), or any code that you do not control. ☆*PhistucK* On Fri, Jan 16, 2015 at 6:38 PM, Patrick H. Lauke <redux@splintered.co.uk> wrote: > On 16/01/2015 16:36, PhistucK wrote: > >> I am actually not sure this proposal is even the right way forward, >> really. >> >> There should not be touch only websites and without the compatibility >> mouse events, or Pointer Events, you must implement event registration >> for every input. I think the way forward is to avoid that. >> > > It's not about preventing mouse events in general, but suppressing only > the generation of those that are the result of a touch interaction (meaning > devs still should register handlers for keyboard, mouse, touch, but at > least they won't have to de-dupe mouse events that were the result of a > touch) > > > 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 16:47:47 UTC