Re: Compatibility mouse events, take 2?

I've been wondering if there should be a opt-out mode for the user agents dispatching backwards compatibility events in the long run.

Applications that need to work with non-PE/TE capable user agents need event handlers for mouse events, but they will most likely
have to make sure that when the PE/TE handlers are being used, the mouse handlers don't do anything. I haven't quite tested how
one would implement this, but from the back of my head it sounds like lots of carefully placed preventDefaults, or only setting up
select handlers during initialization.

I'm not sure what the best mechanism for this would be (Probably not another meta, that's for sure) but a opt-out for compatibility
events sounds like a useful thing to have.

Random strange thought re. TE: for user agents which only expose TE when there is a touch input device present, how should
the user agents notify the pages if the user just plugged in a touch input capable monitor after the application initialized? Requiring
the user to reload all pages doesn't sound like the best option.

> On Apr 1, 2015, at 4:30 AM, Rick Byers <rbyers@chromium.org> wrote:
> 
> I raised this question on the last PEWG call <http://www.w3.org/2015/03/17-pointerevents-minutes.html> as part of the decision to extend the charter and begin work on the next version of the spec and Jacob agreed:
> 
> RB: think IE could be in violation of the mouse compat part of the spec so we might want to address that
> JR: yes, good point
> 
> IIRC he tried to weasel out of calling the latest IE builds in violation of the spec by saying that portion of the spec was optional anyway, but that's just semantics.  Big picture, we should aim for the simplest mouse event compatibility mode we can precisely define that is adequately compatible and so can be supported consistently across browsers.
> 
> I believe Jacob said that they currently use this new mouse event mode only when touch events are enabled for the site, but that was an implementation detail which could change.  Basically we all agree that with PE the mouse events become legacy and their only purpose is to satisfy existing code.  New code shouldn't need to care about the mouse events at all when pointer events are supported.  So it's OK for the mapping to be a little ugly IMHO (back compat always is).
> 
> Rick
> 
> 
> On Tue, Mar 31, 2015 at 11:10 AM, Arthur Stolyar <nekr.fabula@gmail.com <mailto:nekr.fabula@gmail.com>> wrote:
> I believe order should be always the same, otherwise it will introduce much more fragmentation. I mean, all vendors should decide new order which works fine with TouchEvents and then deprecate order in current recommendation (aka IE<12). Since Pointer Events are not so much popular it should not break too much on the Web, however, I may break WinRT html app. So we absolutely need here feedback from IE team.
> 
> 2015-03-31 17:51 GMT+03:00 Patrick H. Lauke <redux@splintered.co.uk <mailto:redux@splintered.co.uk>>:
> Just wondering, now that Pointer Events just through W3C Rec, if http://www.w3.org/TR/pointerevents/#compatibility-mapping-with-mouse-events <http://www.w3.org/TR/pointerevents/#compatibility-mapping-with-mouse-events> isn't at risk now of already being obsolete, since it only reflects current IE 11's implementation, and since Microsoft's Spartan is already going for a different event order which is more compatible with the way mouse events are dispatched in Touch Events?
> 
> pointerover > pointerenter > pointerdown > touchstart > focus > (gotpointercapture) > pointermove > pointerup > touchend > (lostpointercapture) > mouseover > mouseenter > mousemove > mousedown > mouseup > click > pointerout > pointerleave
> 
> (see last few rows in http://patrickhlauke.github.io/touch/tests/results/#desktop-touchscreen-events <http://patrickhlauke.github.io/touch/tests/results/#desktop-touchscreen-events>)
> 
> Or is this event order in Spartan only going to come into effect based on heuristics (if it's detected somehow that the page, or one of its components, registers touch* handlers).
> 
> Should there be a clarifying note of sorts? Is this something that needs to wait for PE version 2?
> 
> P
> -- 
> Patrick H. Lauke
> 
> www.splintered.co.uk <http://www.splintered.co.uk/> | https://github.com/patrickhlauke <https://github.com/patrickhlauke>
> http://flickr.com/photos/redux/ <http://flickr.com/photos/redux/> | http://redux.deviantart.com <http://redux.deviantart.com/>
> twitter: @patrick_h_lauke | skype: patrick_h_lauke
> 
> 
> 
> 
> -- 
> @nekrtemplar <https://twitter.com/nekrtemplar>
>