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

Benjamin Poulain benjamin at webkit.org
Tue Dec 4 11:28:23 PST 2012

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.

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

More information about the webkit-dev mailing list