Re: Compatibility mouse events, take 2?

Rick

On Wed, Apr 1, 2015 at 12:48 AM, Sangwhan Moon <sangwhan@iki.fi> wrote:

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

I believe the IE team's guidance has been to feature-detect for PE and
listen only for pointer events when it's supported, otherwise listen for
mouse/touch.  So the only mouse/touch handlers on a page should be for the
code that doesn't support PE.  This is _much_ simpler than what we've got
with touch+mouse events today (where developers really would prefer to
listen to one or the other, but we've argued they must listen to both).

Assuming this approach works well for developers, then I that's basically
the opt-out API - we don't need something more (no listeners is the same
thing as not firing the events in the first place).

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

Yeah this is a problem with TE.  Previously my thinking was that the only
rational thing to do was to enable the TouchEvents API all the time (and
force sites to update to expect it to be present).  I still think that's
the right solution, but I'm not sure the compat pain will be worth it now
if we see TE as legacy.  TE will still be around for a very long time, so
perhaps it's still worth trying to get rid of this irrational "touch event
API present only if there was a touchscreen at page load" behavior.

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