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

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

Anyway, in the absence of any concrete performance benefit, I think this
comes down to a tradeoff between uniformity and ease of use for mouse-only
scenarios.  You could argue that uniformity would mean that more websites
would just work with touch by default, but I don't personally believe you
can really make a website work well with touch without touch-specific
design work and testing (hit target sizes, etc.), so this argument holds no
weight with me.  Which leaves me thinking that keeping developers lives
easier when working with mouse is the better tradeoff.

Other thoughts?  Thanks for bringing this up.

Rick

On Wed, Jun 19, 2013 at 7:12 PM, Daniel Freedman <dfreedm@google.com> wrote:

> I had a really good conversation with some of the other Polymer developers
> today about how touch-action is supposed to work. They brought up a really
> good point: *it's strange that touch-action only matters for touch input.
> *
> *
> *
> In particular, it seems odd that the story of PointerEvents is that all
> the input methods will behave the same, but mouse and pen could have more
> fidelity than touch by default. By this I mean that it seems strange that
> pointermove would occur for mouse and pen devices regardless of
> touch-action value, but touch input needs to have touch-action: none set to
> receive events.
>
> Rather than attempt to make touches always emit pointermove, which would
> clearly be problematic for scrolling, I suggest that we make pen and mouse
> not emit pointermove by default, and only emit pointermove with the same
> values of touch-action would emit pointermove for touch currently. While
> this would mean more work for the developer, it would be less surprising
> than receiving completely different sets of events from touch as from mouse
> and pen.
>
> Thoughts?
>