Fwd: Re: Phasing out mouse compatibility events on tap?

[Patrick H. Lauke]

Oops, forgot to keep input-dev in CC


-------- Forwarded Message --------
Subject: Re: Phasing out mouse compatibility events on tap?
Date: Fri, 16 Jan 2015 21:56:48 +0000
From: Patrick H. Lauke <re...@splintered.co.uk>
To: public-to...@w3.org

On 16/01/2015 21:18, Rick Byers wrote:
> On Fri, Jan 16, 2015 at 4:04 PM, Patrick H. Lauke
> <re...@splintered.co.uk <mailto:re...@splintered.co.uk>> wrote:

> Only question is: as "click" is currently handled as a compatibility
> event as well in the TE model, would the above also kill "click"?
>
>
> Why do you say click is handled as a compatibility event?

I was basing that on the behavior I observed following
preventDefault...but fair enough, as TE doesn't currently define what is
and isn't a compat event, this was purely my gut assumption.

> I consider TE
> to be pretty similar to PE in the regard that "mouse*" events are for
> compat, but "click" supplies real semantics / value outside of compat

Oh, I agree. Again, was basing this - erroneously perhaps - on my
observation of what happens when you preventDefault.

> var clickEvent = ('ontouchstart' in window ? 'touchend' : 'click');
> blah.addEventListener(__clickEvent, function() { ... }, false);
>
>
> Whoa - detecting a 'tap' is more involved than that in practice. You
> don't want your 'click' function to fire for every swipe, or fire
> multiple times after a multi-touch, right?

This code isn't mine, and it's simplified, but mirror stuff I've
actually seen used in practice in the wild as a "performance trick" to
remove the 300ms back in the day.

Ok, so if this proposal is purely about suppressing the various
mouseover > mousemove > mousedown > mouseup compat event sequences, then
it won't help with the above naive 300ms circumvention I've seen. What
use cases are you thinking of then? Things like dropdowns/panels
appearing on mouseover (as we can then programmatically suppress that
mouseover compat from being fired, so any incoming mouseover is
guaranteed to be from an actual mouse)? If so, I'd still tend toward
method on event :) (and I guess the "don't fire twice...once for
touchend, once for click" type scenario can be disambiguated with the
other proposed way of signalling that the click was derived from a touch
action).

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

[Jacob Rossi]

[Adding input-dev back]

I'm not sure I understand the value/premise. IE currently fires the Pointer Events model for compatibility mouse events but we've been experimenting with trying the more simplified Touch Events model for better interoperability (we'll probably expose this under a flag initially to see how it goes). So this means our latest codebase handles Pointer Events, Touch Events, and also two models for Mouse Events (if we decide to ship the TE model, we'll probably delete the code for the PE model...but that's yet to be decided).

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.

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.

-Jacob

* It probably goes without saying, but I agree with the earlier comments in this thread that such an API might actually be a developer/user *loss* because it might encourage more touch-only sites.

[Patrick H. Lauke]

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

[Rick Byers]

[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 <matt...@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 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