Re: Pointer Events and default browser behaviour

[Adding the list back]

On Thu, Aug 1, 2013 at 11:38 AM, Klemen Slavič <krof.drakula@gmail.com>wrote:

> Ah, yes, good point, I wasn't aware of pointerdown and pointercancel being
> triggered regardless of touch-action. I guess that would suffice for
> scenarios where a user is still allowed to scroll while allowing for touch
> detection. The tests I ran involved detecting all events and didn't mark
> which events were missing from the interaction tests and which did happen.
>
Excellent! Sounds like pointer events should be better for you than touch
events then.  Right?

>  I was primarily worried about having to capture events to detect this
> while still allowing the user to scroll or swipe pages, e.g. magazine apps
> that use WebViews or iframes to embed ads. In those cases, tracking
> interaction would have cancelled default behaviour and prevented the user
> from flipping pages when starting a swipe action on the ad unit.
>

Yes it sounds to me like you NEVER want to call preventDefault or change
the touch-action, right?  Just passively listen for events.

<iframe> and <webview> add some complexity here that I haven't thought
through entirely.  In general handlers inside of an iframe won't receive
all events sent to the window, but (with normal cross-domain restrictions)
I suppose they could inject code into the main document to do the event
monitoring.  I'm not sure exactly under what circumstances a top-level
document can receive all events that originate on top of a child document -
eg. I think <webview> may consume the events without exposing them to the
top-level document at all.  This gets more complicated in multi-touch
scenarios - eg. one touch inside an iframe, one touch outside.  But I'm
guessing that's not too important for your use cases.

> Also, I prefer to use event propagation when handling events and am aware
> of the performance impact, which is why sometimes I use a tradeoff between
> code simplicity and performance. Either way, delegating events enables me
> to check whether an element is, say, an <a href> link and not prevent
> default action when touched. In that scenario, being contained in a
> touch-action: none container, would it suffice to simply put a CSS rule for
> <a> elements with touch-action: auto, or will the parent override that
> behaviour? This is especially important for input elements as well where
> cancelling default behaviour will completely prohibit interaction with
> those elements in WebKit, for example.
>
touch-action doesn't affect things like link clicking - just panning and
zooming.  I wouldn't expect that you'd want to muck with touch-action on
anything at all when doing interaction monitoring.