W3C home > Mailing lists > Public > public-pointer-events@w3.org > July to September 2013

Pointer Events and default browser behaviour

From: Klemen Slavič <krof.drakula@gmail.com>
Date: Tue, 30 Jul 2013 18:35:25 -0700
Message-ID: <CACqinmgrMPdF9CV5rza_6Sd7QQzue9DfpcQyT6MK67Uu5hPSKQ@mail.gmail.com>
To: public-pointer-events@w3.org
Hello all,

As per my Twitter
exchange<https://twitter.com/jacobrossi/status/362320494843797505> I'm
writing about the implementation of the Pointer Events spec in Internet
Explorer 10, specifically, regarding the mutual exclusivity between
generating Pointer Events and default browser behaviour.

My gripe with this situation is that it prohibits *pass-thru* observation
of events when the event's default behaviour is not prevented.

Consider a situation where an ad is embedded within another through the use
of a wrapping element (pretty common in the advertising space, where the
more common use is an <iframe> element; also, disclaimer, I work for a rich
media ad company <http://www.celtra.com/>). In such a case it would be in
the interest of the user to be able to scroll the page even though the
touch was initiated within the ad container.

In the case of WebKit- and Gecko-based browsers, one can attach event
listeners in the bubble phase to detect interaction, letting the user
scroll unless interacting with a touch-capturing element (carousels and
such):

document.body.addEventListener('touchstart', function(ev) {
  // interaction tracking code, never calling ev.preventDefault()
  ...
}, false);

// some component inside the DOM hierarchy
var div = document.querySelector('#carousel');
div.addEventListener('touchmove', function(ev) {
  // prevent scrolling, since we'd like the user to interact
  ev.preventDefault();
  ...
}, false);

Interacting with *#carousel* will block scrolling and will generate touch
events, but detection of interaction elsewhere in the document will still
allow the user to scroll the content and parent page (if there's nowhere to
scroll the <iframe> content, depending on the length of the swipe).

This is where we hit a snag; to provide similar interaction behaviour for
touch using Pointer Events, we have to add the *-ms-touch-action* attribute
to the elements we want to have Pointer Events generated for:

body { -ms-touch-action: none; }

This enables us to listen for events, whether they're mouse, touch or pen
input:

document.body.addEventListener('MSPointerDown', function(ev) {
  // interaction tracking code, no ev.preventDefault();
  ...
}, false);

var div = document.querySelector('#carousel');
div.addEventListener('MSPointerMove', function(ev) {
  // no need for ev.preventDefault();
  ...
}, false);

The very act of observing Pointer Events on the body without preventing the
default action prevents the user from scrolling the contents. In WebKit and
Gecko-based browsers you can simply prevent default action anywhere within
the capture and bubble phase, but with Pointer Events, you cannot decide on
the fly, relying on explicit user interaction that toggles the CSS
attribute between these modes using other events such as simulated mouse
clicks. Kind of like the "click to play" used in plugin-based games to
enable Pointer Events and escape when you want to conclude interaction.

My question is, is there a way to have both? To be able to passively
monitor touch events within the Pointer Events model without blocking
scrolling? The only other solution that comes to mind is forwarding calls
to various scrolling functions, which is far from ideal and prone to
various glitches.

-- 
* <http://about.me/klemen.slavic>
*
*
*
*Sent from my fusion-powered solar dome in geosynchronous orbit.*
Received on Thursday, 1 August 2013 09:20:45 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:20:25 UTC