Re: Pointer Events and default browser behaviour

Thanks for your feedback Klemen!

I don't think we're normally thinking of "interaction monitoring"
scenarios, and full-fidelity interaction monitoring is definitely on
conflict with the notion that we don't want to send events while scrolling.

Can you explain a little more of the use case?  Why is it useful to know
where the user is touching the screen when scrolling the page?  Eg. I see
that users often scroll the chromebook pixel in the bottom left/right
corners since that's a convenient place to hold your hands and put your
thumbs.  This also tends to overlap with ads, but in no means represents
the user interacting with the ad.

If you leave touch-action as 'auto' you'll still get a pointerdown
(probably a couple pointermove) and pointercancel event on the element the
user touches when scrolling.  Why isn't that sufficient?  What's the
additional value in getting all the pointermove and pointerend events for a
scroll gesture?

This must also be an issue for you in some scenarios with touch events,
right?  Eg. Chrome Android basically follows the PE model - sending a
touchcancel as soon as scrolling starts.  Mobile Safari will often (eg.
when scrolling the document) just omit all touchmove events while
scrolling.  Are either of these cases alright for you today?

Also note that the simple act of having a touchstart handler on the body is
bad for scrolling performance.  It means that we can never start scrolling
the page without blocking on the main thread / javascript (particularly bad
on mobile - eg. means a page often can't be scrolled while it's still
loading).  See
https://plus.sandbox.google.com/115788095648461403871/posts/LXKEENhnQSD for
more details and a new feature in chrome that warns web developers about
this scenario on their site.  Now that dev tools exposes this, you might
find page owners getting upset about ads that add touchstart handlers to
the body.

Thanks to touch-action, PE can do much better than this.  Your JS can still
monitor all  pointerdown events on the document but scrolling can still
start immediately on the impl thread (since in touch-action: auto regions
there's no way to prevent the scrolling).

Rick



On Tue, Jul 30, 2013 at 9:35 PM, Klemen Slavič <krof.drakula@gmail.com>wrote:

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