Re: Internet Explorer Mobile Touch Events support

On Fri, Aug 1, 2014 at 2:38 PM, Jacob Rossi <Jacob.Rossi@microsoft.com>
wrote:

> On Thu, Jul 31, 2014 at 5:28 PM, Patrick H. Lauke <redux@splintered.co.uk>
> wrote:
> >
> > On 31/07/2014 18:38, Jacob Rossi wrote:
> >>
> >> Supporting Touch Events is our next step in helping rationalize these
> >> two models together as it gives us the implementation experience to help
> >> contribute to this group with how Pointer and Touch Events coexist,
> >> enables a compatible web experience for our users today, and makes it
> >> smoother for web developers to transition their sites from Touch to
> Pointer.
> >>
> >> Going forward, we continue to see Pointer Events as the best model for
> >> the web. In the blog post, you’ll see that we did an experiment with
> >> Touch Events on devices that support other input modalities like mouse
> >> and keyboard. What we found was that about 10% of top sites were broken
> >> for mouse/keyboard users due to coding patterns that assume Touch Events
> >> support means touch-only devices (we’ll share the specific site data
> >> once I’ve compiled it in a digestible form).  This is one example of why
> >> we’ll continue to encourage developers to use Pointer Events.  It’s also
> >> one reason why (for the time being) we intend for Touch Events to be in
> >> IE mobile only.
> >>
> >> If you have questions or concerns, don’t hesitate to ask.
> >
> >
> > Is it too early to ask how, exactly, this will shake out on pages that
> register handlers for BOTH touch and pointer events? Will PEs take
> precedence? What about handlers that are added dynamically a lot later than
> on page load?
>
> There is no precedence model here--we support both event models side by
> side. Pointer fires, then touch, then mouse. For example:
>         pointerdown, touchstart, mousedown
> Note that mouse events still follow the "interlaced" firing described by
> the pointer events spec (not the click sequence firing described by touch
> events). Any touch-action rules are honored even if touch events are in use
> (yes, you can have touch-action: pan-x but still prevent the pan-x by
> cancelling the touchstart event). As expected, there's a measurable
> performance improvement for panning and zooming when touch events are not
> in use.
>
> We've come a cross one or two instances of sites having issues by
> inadvertently registered for both pointer & touch events. We've also seen
> one or two instances of sites registering for both touch and mouse events
> and expecting the ordering to follow the touch events behavior.  But so
> far, these have not appeared to be recurring patterns (though our
> implementation experience is still young).
>
> We'll encourage patterns like:
>
> if (window.PointerEvent) {
>         elm.addEventListener("pointerdown", fn);
> } else {
>         elm.addEventListener("touchstart", fn);
>         elm.addEventListener("mousedown", fn);
> }
>

Thanks for the details Jacob!  This sounds very similar to the design I
favored
<https://docs.google.com/a/chromium.org/document/d/1Sasl1qYJV6agrDvGplEYlZznzc38U-TFN_3a67-nlSc/edit#heading=h.qa5z97xesbty>
when I started thinking about the interaction a couple years ago (with the
not-surprising difference that for Chrome we felt we'd have to maintain our
on-click style of mouse event emulation when pointer events weren't in use,
and the associated complexity that would add).

Does cancelling the pointer event suppress the touch event as well?

Also, any idea how this matches Firefox's approach for supporting both
types of events?  I know at one point they were considering an either-or
model of firing the events, but hopefully I persuaded them that would be a
bad idea.

Do you think we should try to get this interaction added to a spec or other
W3C published document somehow?

 > (And any indication when the update will be pushed out on the 8.1
> developer preview channel? And/or would it be possible to send a note to
> the list when it is out, just so we can start testing things?)
>
> Next week this will be available via the existing Developer Preview
> channel for Windows Phone (if you're already opted in and on WP 8.1, then
> you'll get prompted for the update).  Our phone emulator will also be
> available at that time. Both can be debugged remotely via Visual Studio
> (including the free version).  I'll let the groups know when this happens.
> Instructions for getting your phone onto the Developer Preview program are
> here: http://dev.windows.com/en-us/develop/devpreview
>
> -Jacob
>