Re: Why doesn't touch-action affect pointerType mouse?

Thanks for the response, and for noting that this has come up before. I
just want to register that the Polymer team thinks the current utility of
touch-action being unnecessary for mouse is questionable, because web
component authors will want their code to work on mobile as well as
desktop, and touch-action will have to be used defensively to ensure the
right event situation. That said, PointerEvents is such a massive benefit
that shipping with a few rough edges (though well thought out) is much
preferable to nothing at all :).


On Thu, Jun 20, 2013 at 9:35 AM, Jacob Rossi <Jacob.Rossi@microsoft.com>wrote:

> 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
>
>
>