Re: Pointer Events and default browser behaviour

I've given this some more thoughts, and yes, Pointer Events do seem to be
the better pick when it comes to abstracting and standardizing on one set
of events. Currently, we've decided to translate those events to touch
events to support our legacy components and third-party API clients, so
that everything uses the same baseline event set without having to worry
about cross-browser issues. Hopefully we can migrate to Pointer Events
when/if enough browsers support it.


On 1 August 2013 09:51, Rick Byers <rbyers@google.com> wrote:

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


-- 
* <http://about.me/klemen.slavic>
*
*
*
*Sent from my fusion-powered solar dome in geosynchronous orbit.*