On Tue, Dec 4, 2012 at 10:34 AM, Rick Byers <rby...@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
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
