Re: Phasing out mouse compatibility events on tap?

On Fri, Jan 16, 2015 at 12:16 PM, PhistucK <phistuck@gmail.com> wrote:

> Comments inline.
>
> ☆*Phistu*
> On Fri, Jan 16, 2015 at 6:55 PM, Arthur Stolyar <nekr.fabula@gmail.com>
> wrote:
>
>> Hi PhistucK,
>>
>> 2015-01-16 18:46 GMT+02:00 PhistucK <phistuck@gmail.com>:
>>
>>> 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.
>>>
>>
>> Pointer Events are good, but we do not talk here about them.
>>
>>
>>>
>>> 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).
>>>
>>
>> This is possible aready by only using touchevents and do not using mouse
>> events. Touch events does not has backcompatibility already, so if you will
>> add right now only touch events, then desktop sites with mouse will not
>> work anyway.
>>
>
> Right, but this gives developer an incentive - use touch events, disable
> compatibility​ mouse events and you get better performance.
>
>
>
>>
>>
>>> - It can interfere with third party scripts you may add (even analytical
>>> ones), or any code that you do not control.
>>>
>>
>> Yes. This is why this choise whould be on developer side, not on browser
>> side. So developer can disable compatibility events or not. This is only
>> optimization and not one should/might use it.
>>
>
> This is problematic, too. You may not know whether third party scripts use
> them or not​ and these issues are usually hard to diagnose when you are not
> familiar with the situation ("I used this to get better performance but I
> do not really understand the changes it causes, I just copied and pasted
> it").
>

This, I think, is the best argument against adding such an API.  Developers
of one component may use it and cause problems in another component that
end up causing a lot of confusion and frustration.  If we can't reasonably
expect to get rid of them consistently, then perhaps adding an API which
just increases the number of things you need to understand actually makes
the rationality of the platform worse, not better.

In general, I agree about whole Pointer Events thing, but it's unfortunate
>> to start talking about them again and again.
>> --
>> @nekrtemplar <https://twitter.com/nekrtemplar>
>>
>
>