Re: Touch scrolling after preventDefault called on first touchmove event

If we used: "If *any* touchmove event is cancelled", then I think Firefox
would be in violation of the spec, as they only depend on whether or not
the first touchmove event is cancelled.

Would this be preferable?

"A touchmove event should cause no default action until a touchmove
event associated with the same active touch point is not cancelled."

Tim


On Thu, Jul 17, 2014 at 4:53 PM, <cathy.chan@nokia.com> wrote:

>  I’m not sure I understand the meaning of “If every touchmove event of an
> active touch point is cancelled”. To make the conclusion that **every**
> touchmove event is cancelled, the UA would have to wait until **all**
> touchmove events have been triggered and cancelled, which does not make
> sense.
>
>
>
> Perhaps what you really mean is that “If **any** touchmove event of an
> active touch point is cancelled, it should prevent any default action
> caused by that touchmove event, such as scrolling.” But that’s pretty much
> what preventDefault generally means. If that’s indeed the case, maybe we
> don’t need that sentence at all.
>
>
>
> From Section 8 Glossary:
>
>
>
> [[preventDefault
>
>     If a event is cancelable, the preventDefault method is used to signify
> that the event is to be canceled, and any default actions defined in the
> user agent as a result of this event, or consequential events from the
> canceled event will not occur. Calling this method on non-cancelable events
> will have no effect. ]]
>
>
>
> - Cathy.
>
>
>
> *From:* tdresser@google.com [mailto:tdresser@google.com] *On Behalf Of *ext
> Timothy Dresser
> *Sent:* Thursday, July 17, 2014 12:46 PM
> *To:* Rick Byers
> *Cc:* Kornel Lesiński; public-touchevents@w3.org
> *Subject:* 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
>
>
>
>
>
>
>
>