Re: Compatibility mouse events, take 2?

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>
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>:
>
>> Just wondering, now that Pointer Events just through W3C Rec, if
>> 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)
>>
>> 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 | https://github.com/patrickhlauke
>> http://flickr.com/photos/redux/ | http://redux.deviantart.com
>> twitter: @patrick_h_lauke | skype: patrick_h_lauke
>>
>>
>
>
> --
> @nekrtemplar <https://twitter.com/nekrtemplar>
>