Re: Internet Explorer Mobile Touch Events support

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

>
> On Fri, Aug 1, 2014 at 11:46 AM, Rick Byers <rbyers@google.com> wrote:
> >
> > 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 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).
>
> Given our other mobile changes are targeted at getting the same mobile
> content as Chrome/Safari for iOS/Android, perhaps our success with keeping
> mouse events per the pointer events spec suggests the simplified touch
> events model for mouse isn't necessary for compatibility. Have you ever
> prototyped the interlaced model to see what happens?
>

No, I've never tried.  Outside of the other benefits of pointer events it
hasn't seemed sufficiently valuable to push on and create behavior
fragmentation around.  Migrating code designed for mouse to touch events is
probably still just as hard.

Do you also send touchmove and mousemove events in touch-action: none
regions?  That would certainly improve compat with mouse-specific websites.
 Maybe now that we have touch-action we should consider that.  Eg. we've
got an ugly hack to translate touch events into mouse for non-touch-aware
plugins like Flash.  If we could instead just make them touch-action: none
that would be a lot cleaner.

So if someone calls preventDefault just on touchend but not touchstart,
they'll get a mousedown with no mouseup/click?  That seems like a potential
problem.  We often recommend cancelling just the touchend to suppress the
mouse/click events without disabling scrolling/zooming.  I guess we should
try to modify our guidance now somehow ;-)

> Does cancelling the pointer event suppress the touch event as well?
> Yes.
>
> > 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.
>
> I'll defer to Matt. But I believe it's very similar.
>
> > Do you think we should try to get this interaction added to a spec or
> other W3C published document somehow?
>
> I think we could start with a light-weight guidance document in the Touch
> Events CG. Perhaps a wiki page.
>