[webkit-dev] pointer events specification - first editors draft

[Rick Byers]

On Tue, Dec 4, 2012 at 2:28 PM, Benjamin Poulain <benjamin at webkit.org> wrote:
> On Tue, Dec 4, 2012 at 10:34 AM, Rick Byers <rbyers at chromium.org> wrote:
>>
>> >> The premise of the specification is that using mouse event and touch
>> >> events
>> >> interchangeably is needed. In reality, nobody was really asking for
>> >> that
>> >> because it is a terrible idea. You can already easily unify pen, touch
>> >> and
>> >> mouse by writing very little JavaScript, but it is only useful in very
>> >> few
>> >> cases.
>>
>> It's not accurate to say "nobody" is asking for it.   I agree that you
>> generally need to design explicitly for touch and mouse interactions, and
>> it's a legitimate concern that having a unified model may encourage
>> developers to ignore important differences.  However, developers are already
>> attempting to unify the events today when the right design involves treating
>> single-finger touch actions the same as mouse actions.  For example, Google
>> maps transforms both touch events and mouse events to a common unified event
>> system, as does the PlayN game engine (http://code.google.com/p/playn/).
>> There has been at least SOME positive response in the web developer
>> community to the idea of a unified event model, so I don't think it's fair
>> to dismiss this idea as having no value out of hand.
>
>
> That is just reiterating my point.
> The fact is applications have already easily unified touch and mouse for the
> rare cases where it is needed.
>
>>
>> >> In particular, having apps state clearly and declaratively [3] whether
>> >> a touch that starts on an
>> >> element should result in browser behavior like scrolling or events
>> >> which can be handled from
>> >> JavaScript is potentially a big win for touch scrolling performance
>> >> (something we struggle with in Chrome).
>> >
>> > This is a straw man.
>> > Chromium has implementation issues there, adding a new spec is not the
>> > solution to your problems.
>> >
>> > Having touch-action == "auto", the default, will have the exact same
>> > issues as you have today.
>> > Having touch-action == "none" does not buy you much since it would have
>> > been implemented
>> > today by responding to the very first event.
>>
>> This is incorrect.  Let me ellaborate on the benefit here.  The
>> fundamental difference between the two models is that touch events imply
>> (although it's not well specified, and implementations differ) that it's
>> possible to receive touchmove events while an element is being scrolled.  In
>> such a case, we can't really do threaded scrolling (especially if calling
>> preventDefault on the touchmove is supposed to stop scrolling at that
>> point).  This makes it incredibly easy for web developers to accidentally
>> defeat fast scrolling optimizations (just by having a touchmove handler on
>> an element which happens to contain a scrollable div).  For example,
>> http://store.apple.com/us has a touchmove handler on the document (for no
>> apparent good reason that I can see), which means that (in the chrome
>> desktop implementation at least), we're unable to do scrolling without
>> blocking on the main webkit thread because the page might really be
>> expecting to receive events for the touch.  In rare scenarios (when an app
>> needs to receive touchmove events for a parent element, but one if it's
>> children is scrollable) threaded scrolling appears impossible without
>> potentially breaking changes to the touchevent model.
>>
>> Pointer events, on the other hand, were designed from the start to avoid
>> this issue.  They require the developer to explicitly state whether they
>> want scrolling OR events.  The spec is explicit that you will NOT receive
>> events when the browser is performing a default action like scrolling.  So
>> "touch-action: auto" means that once a scroll gesture is detected (even when
>> the element itself isn't actually scrollable), you get a pointercancel event
>> indicating that the page will no longer receive events for the touch.  If
>> the developer REALLY wants to get all the events, they have to explicitly
>> state that they're disabling scrolling on the element with touch-action:
>> none.   IMHO, it's far better to require developers to make an explicit
>> trade-off between scrolling and app-level events, than it is to let them
>> believe they can have it both ways without appreciating the performance
>> implications.  I question whether a modern touch API should even give
>> developers the option of having janky scrolling, nevermind whether it should
>> be so easy to opt-in to that mode accidentally.
>
>
> Tell me where it is said touch events have to works like you described.
> Multiple implementations, running on phones, have very efficient scrolling
> despite having handling for touch events. I am amazed you made an argument
> out of this.

Nowhere does it say touch events have to work this way, that's part of
the point - much of the behavior of touch events is still undocumented
and unspecified.  If we're going to make the implementations better
while exposing a consistent model to applications, we need to document
this sort of thing somewhere.

Here is a stupid sample app that demonstrates when scrolling is
blocked by touchmove handlers:
http://www.rbyers.net/janky-touch-scroll.html.  On iOS (6.0 runnin on
a new iPad) and on chrome desktop (running on Win8) there is
periodically a 200ms pause when scrolling with touch (touchmove
handler doing a lot of work).  It's true that Chrome for Android
doesn't have this issue (this is what I was referring to when I said
implementations differ), but we're unsure how many sites are broken by
this difference in behavior and we all want iteroperability afterall -
not different performance vs. functionality trade-offs in different
implementations.

>
> Benjamin