Re: Touch scrolling after preventDefault called on first touchmove event

Thanks Tim.  As Safari has always (AFAIK) had this behavior, correcting the
V1 spec to permit it (without disallowing the Firefox behavior) is the
right thing to do here I think.  It's unfortunate that the spec has so many
implementation defined behaviors, but that's the reality of v1
retro-speccing the implementations.  So this change LGTM.

Rick


On Tue, Jul 15, 2014 at 6:38 AM, Timothy Dresser <tdresser@google.com>
wrote:

> I've updated the v1-errata branch of the spec to reflect this change.
>
> The diff can be seen at https://dvcs.w3.org/hg/webevents/rev/e52f9e5c93cd.
>
> The updated version of the spec can be seen at
> https://dvcs.w3.org/hg/webevents/raw-file/v1-errata/touchevents.html#the-touchmove-event
> .
>
> Please let me know if you have any feedback,
> Tim
>
>
> On Fri, Apr 18, 2014 at 7:37 PM, Kornel Lesiński <kornel@geekhood.net>
> wrote:
>
>> On 17.04.2014, at 20:20, Timothy Dresser <tdresser@chromium.org> wrote:
>>
>> > We’re thinking of modifying the way chromium behaves when the
>> preventDefault method is called on the first touchmove event of an active
>> touch point.. This currently prevents the active touch point from ever
>> causing scrolling, but we are considering allowing scrolling to begin later
>> if additional touchmove events are received which have not had their
>> preventDefault method called. This does not deviate significantly from
>> existing browser behaviors and increases the expressiveness of touch events
>> in chromium.
>>
>> I think that's an excellent change.
>>
>> AFAIK Firefox for Android implements the spec quite literally — only the
>> first touchmove can control scrolling, and there is no unspecified magic
>> suppressing touchmove events (WebKit has delay/threshold that prevents
>> touchmove being sent too early), and as a result Firefox is very hard to
>> work with, e.g. it's impossible to reliably control scrolling in response
>> to a "tap and hold" gesture, because user can't hold their finger without
>> causing several (tiny) touchmove events.
>>
>>
>> I've tried to implement a scrollable list with swiping and reordering,
>> which I think is a pretty basic building block for apps, but I found that
>> neither touch-action nor preventDefault as currently specced offer enough
>> control to do it well.
>>
>> My requirements were:
>>
>> 1. Fast vertical flick should block scrolling in both directions (swipe
>> gesture shouldn't move the page, even if movement isn't perfectly
>> horizontal)
>> 1b. Ideally, slow vertical movement should allow scroll (normal behavior
>> if movement is slower than a flick)
>>
>> 2. Horizontal movement should scroll, except when disabled in case 3
>>
>> 3. After "tap and hold" for 300ms the page should not scroll (to allow JS
>> to drag an element)
>> 3b. Ideally, it should be possible to scroll when the second finger
>> touches the screen (one finger drags the element, second finger moves the
>> page), but that's rare enough that I can do that by emulating scrolling
>> with scrollTop/etc.
>>
>> https://pornel.net/slip/
>>
>> I think I could do pretty well if I could hold off native scrolling for
>> as long as I need and let it scroll when I finish recognizing gesture user
>> is trying to make. Otherwise, if browsers actually follow the spec as
>> currently written, I'll have to always block scrolling on the first
>> touchmove, then process gestures, and then resort to janky emulation of
>> scrolling.
>>
>>
>> Can you make the better scrolling behavior feature-detectable? Maybe a
>> special value of event.cancelable? Currently browsers set
>> event.cancelable=true for touchmove events even when they don't listen to
>> cancellation.
>>
>>
>> Also, while the scrolling is prevented, do those events still count
>> towards scroll offset that will be set when scrolling is allowed? When I
>> cease blocking scrolling, will the browser "resume" the original scroll
>> action (finger is going to "stick" to touchstart position) or will
>> scrolling start fresh from the point it was allowed (finger will "stick" to
>> the first non-prevented touchmove location)?
>>
>> Let's say user touched the screen, I prevented scrolling while finger
>> moved 100 pixels, then I allow scrolling. Will the next 1-pixel finger move
>> change scroll offset by 101 pixels or 1 pixels?
>>
>> In the former case the scroll start may look glitchy, but the page will
>> stick to the finger like user expects. In the latter case there will be no
>> visual jump, but from user's perspective their finger will slide by 100
>> pixels, which may feel unnatural.
>>
>> To me either way is fine, as long as the behavior is specified, so that I
>> can choose desired behavior by "correcting" scroll offset before letting
>> browser scroll (or using any other method you suggest). For small moves
>> (like a 15-pixel threshold for detecting movement direction) I'd prefer
>> browser to follow touchstart location, so that if I don't detect a custom
>> gesture I can pretend blocking never happened.
>>
>> --
>> regards, Kornel
>>
>>
>>
>>
>