On Tue, Dec 4, 2012 at 2:28 PM, Benjamin Poulain <benja...@webkit.org> wrote: > 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.
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 _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
