Re: Phasing out mouse compatibility events on tap?

[Fixing crazy subject]

Sorry I missed this Matt (because of the different subject) before my most
recent reply. Looks to me like our summaries are similar though :-).  A
couple more points inline.

On Mon, Jan 19, 2015 at 4:59 AM, matt gaunt <mattgaunt@chromium.org> wrote:

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

I doubt that will be possible in practice.  For some new device to be
usable on the web in practice, it's going to have to emulate the user
interaction events of some well supported device.  I think this applies to
accessibility scenarios as well.  I see two ways out of that morass:

1) A suitably general definition of interaction events that can be re-used
for new input devices.  This is of course what PointerEvents aims to
achieve, although I think it's also possible (if you can stomach the poor
names - as we have done with 'click') to evolve an existing API
incrementally
<https://docs.google.com/a/chromium.org/document/d/1x-yE4CmTZlZQXea4_FPjgly5TOvF28UBNs9gZ5aGUhg/edit#heading=h.khk014lrt6dl>
to do this nearly as well.

2) Sufficiently powerful "user gesture" events so that most sites stop
relying on the lower level "interaction" events.  Eg. we'd probably need
interoperable "onactive", "onhover", "drag", etc. events to replace the
majority of low level uses.  Accessibility folks have been arguing this
direction for years (decades?) and I'm not convinced we could ever shift
developer mindset here.


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

I agree. No-one looking to design a useful touch experience is going to
intentionally rely on the compatibility mouse events (since they convey no
additional information beyond 'click').  So splitting touch and mouse
cleanly seems like only a net win for touch+mouse support.  We're in this
mess afterall because many developers just stopped listening to mouse
events on "mobile" since they caused them only confusion.

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

Ok, I tend to agree.  Let's chat about this more offline though.  I LOVE
that you're pushing on us to try to give new web developers the simplest /
most rational API possible.  It's way to easy to get hung up on
compatibility defeatism (queue the PE quip here <grin>).

Rick