RE: Internet Explorer Mobile Touch Events support


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?

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

Received on Friday, 1 August 2014 19:29:29 UTC