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

[Benjamin Poulain]

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.

Benjamin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20121204/a688eb21/attachment.html>