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

On Fri, Jun 21, 2013 at 8:24 PM, Daniel Freedman <dfreedm@google.com> wrote:

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

For developers that want to ensuring they're designing for touch and mouse,
perhaps we should encourage (or define in Polmyer) a pattern where
pointermove handlers ASSERT that they're being used in a touch-action: none
region (or otherwise drive move events)?  Perhaps we could be doing
something in the UA / standard to make opting into such a mode
possible/easier?

I don't think any of what Jacob and I have said would preclude allowing
developers to opt-into a mode where they want to be reminded somehow that
they need to use touch-action - we just don't think it's the right default
for most developers...


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