- From: Jacob Rossi <Jacob.Rossi@microsoft.com>
- Date: Thu, 20 Jun 2013 16:35:39 +0000
- To: Rick Byers <rbyers@google.com>, Daniel Freedman <dfreedm@google.com>
- CC: "public-pointer-events@w3.org" <public-pointer-events@w3.org>
On Thu, Jun 20, 2013 at 7:34 AM, Rick Byers <rbyers@google.com> wrote: > > I agree that it's odd that an otherwise pointer-type-agnostic system has this pointer-specific quality. But I do think there's a good reason for it. It's really only touch that (in typical browser UIs) has the ambiguity between application pointer handling and accelerated browser action. We don't need 'touch-action: auto' to suppress generation of pointermove events for mouse because there's not some other thing we'd want to be doing with those events in advance of any JS execution. A designer can design a site for mouse without having to think about the trade off between pointer manipulation and scrolling, and I don't think pointer events should make lives more difficult for developers concerned only with supporting only mouse (that'll just encourage them to stick with mouse events). > > Now there is one analogy for touch-action with mouse - mousewheel events. Ideally we could do mouse scroll scrolling on the compositor thread without blocking on javascript, but if there is a mousewheel handler today that is impossible. But touch-action wouldn't work great here. mousehweel has no explicit begin/end sequence so it can't follow the 'touch-action is consulted as soon as the pointer goes down and remains in effect for the duration of the pointer contact' rule. Perhaps the right way to address mousewheel is with some other new CSS property like wheel-action (which could be a simple boolean - events or scrolling, or it might be nice to allow mousewheel to trigger content zoom on browsers that support it). But there's no point in adding this unless browsers plan to do mousewheel hit testing on the compositor thread. In the end scroll latency just isn't as important for mousewheel because of the psychological difference when your finger is disconnected from what's moving. We have no immediate plans in chromium to extend our compositor hit testing to cover mousehweel (although we did have that scenario in mind when we designed it). Agreed. We explored the notion of making this "pointer-action," but arrived at the same conclusion as Rick. Mouse simply doesn't have the ambiguity that touch does on many implementations. Aligning for consistency's sake just adds frustration. It also would be a substantial breaking change to existing pointer event content. -Jacob
Received on Thursday, 20 June 2013 16:37:34 UTC