Re%3A%20Phasing%20out%20mouse%20compatibility%20events%20on%20tap%3F&In-Reply-To=%3CCAFWyatoU78oqPtxpdwNQq49bw-_6Ly1qjASsKf60cQo0D4wz8g%40mail.gmail.com%3E&References=%3CCAFWyatoU78oqPtxpdwNQq49bw-_6Ly1qjASsKf60cQo0D4wz8g%40mail.gmail.com%3E

Apologies for not getting back to everyone on this sooner.

The way I view the current model of things (and it may be incorrect):

[touchdown, touchmove, touchup, mousedown, mousemove, mouseup] are all
events from a user interaction

[click] are events as the result of a user gesture.

To the best of my knowledge, a set of "user interaction" events will result
in a "user gesture".

The assumptions I've made while questioning killing off mouse compat.
events are:

1.) This just makes a saner web platform API (i.e. a mouseup, mousemove,
mousedown events are fired because of one of them actually happened).

2.) The "user gestures" won't be affected, a click will regardless of a
mouse or touch base gesture.

3.) This will have zero performance gains

4.) Developers wanting to listen to "user interaction" events without
affecting "user gestures" will no longer need to de-dupe mouse events.

5.) The proposal for MouseEvent.firedFrom(“TouchEvent”) is nothing more
than boilerplate to detect this and ignore the event, giving the same
behavior as above.

6.) If you could get touch events without mouse events, this would
encourage developers to set BOTH listeners, rather than check for touch and
only apply that.

7.) This ends the notion of adding compat events for other user
interactions (i.e. stylus, leap motion....whatever the future brings)

Based on this thread:

1.) Little win for developers compared to MouseEvent.firedFrom(“TouchEvent”)

2.) People have learnt the odd way things work, don't change it to add to
confusion

3.) Concern that a global change like this would affect libraries relying
on old behaviour.

4.) Encourages touch only interfaces.

I can't argue against point 1 beyond that I would expect "firedFrom" to
just be boilerplate code for anyone listening to mouse and touch events,
but I confess this is a minor win. Point 2 and 3 come down to a saner API
in my opinion and I would hope this would be the expected behavior by
developers new to the web platform. I can't follow how this would encourage
touch only interfaces. It simplifies using touch and mouse events at the
same time and I would expect most developer to plumb both events through
the same code path to implement custom gestures. The "user gestures"
wouldn't be affect so that shouldn't be of concern.

Based on everything in this thread, I think we should ignore this proposal
and focus on the MouseEvent.firedFrom() API proposal.