W3C home > Mailing lists > Public > public-webevents@w3.org > April to June 2013

Re: Send touchcancel when scrolling starts?

From: Rick Byers <rbyers@google.com>
Date: Wed, 26 Jun 2013 20:41:48 -0400
Message-ID: <CAFUtAY-nKnBjG517JP_PsuHs8z6H0_Gg1aMMDaS5nie-92JQrw@mail.gmail.com>
To: Alexandre Elias <aelias@chromium.org>
Cc: Wes Johnston <wjohnston@mozilla.com>, Tim Abraldes <tabraldes@mozilla.com>, "olli@pettay.fi" <olli@pettay.fi>, Paul Kinlan <paulkinlan@google.com>, "public-webevents@w3.org" <public-webevents@w3.org>, Jim Mathies <jmathies@mozilla.com>, Matt Brubeck <mbrubeck@mozilla.com>, Yufeng Shen <miletus@google.com>
On Wed, Jun 26, 2013 at 8:28 PM, Alexandre Elias <aelias@chromium.org>wrote:

> On Fri, Jun 21, 2013 at 6:53 AM, Rick Byers <rbyers@google.com> wrote:
>
>>
>> I haven't yet been able to find a real-world example of a site
>> legitimately handling touch events while scrolling.  Your side-swipe
>> example seems the most likely, but it'll be broken when zoomed or when
>> horizontal panning is otherwise permitted (I think touch-action: pan-y is a
>> better solution for this).  *Alexandre / Paul*, have you guys come
>> across any sites that actually want this functionality from Android browser
>> / Firefox / iOS?
>>
>
> I haven't come across a compelling real-life example, no.  Certainly there
> are use cases such as horizontal carousels on a vertically scrolling page,
> but in that case it's not clear that allowing both movements at once is
> better than locking to one axis (in my opinion locking is somewhat
> preferable and matches the typical behavior of native touch apps).
>
>
>>
>> So perhaps the main disadvantage of sending the touchcancel is the
>> compatibility implications.  Some developers don't realize they need to
>> listen for it (although this can cause bugs elsewhere too), or that they
>> need to cancel touchmove events they've handled.
>>
>> The main advantage of sending touchcancel is probably that it makes this
>> choice explicit and lowers the risk that touchmove handlers will be
>> accidentally causing reflow or other changes while scrolling.  Also being
>> consistent with the pointer-events model is a benefit, but I think we could
>> still implement touch-action for touch events without this property.  *Alexandre,
>> *any other reason you guys prefer touchcancel to what Firefox is doing?
>>
>
> No, the only benefit I'm aware of is the explicit nature of the
> notification (which in principle may be useful, but in practice I'd be
> surprised if any sites are doing anything with it today).
>

Thanks.  Given that our DevRel team has seen Chrome-Android-specific bugs
in websites as a result of this (and the TouchEvents spec more closely
matches what FF doing), perhaps we should give switching to the FF model a
shot?  We'll take this off list and report back.


>
>
>>
>> Thanks,
>>   Rick
>>
>>
>>>
>>>
>>> - Wes
>>>
>>>
>>
>
Received on Thursday, 27 June 2013 00:42:38 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:03:55 UTC