Re: Touch scrolling after preventDefault called on first touchmove event

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 Tue, Jul 15, 2014 at 10:25 AM, Rick Byers <rbyers@google.com> wrote:

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