Re: [pointerevents] Spec implies mice can't support pressure

On Thu, Jan 21, 2016 at 3:24 PM, Patrick H. Lauke <plauke@paciellogroup.com>
wrote:

> On 21/01/2016 17:58, Ted Dinklocker wrote:
>
>> Assuming that the pressure characteristics of a "force touch"
>> are different between an iPhone and a Mac with a pressure sensitive
>> touchpad, a web developer would have to have detection code and react
>> differently based on the HW platform.
>>
>
> On iPhone, there's the force attribute on touch events. On Mac, the same
> attribute is added (in a non-standard way, of course) to mouse events. So
> the attribute itself is the same, just on different event types (which
> would be irrelevant for PE as our model encompasses both).
>
> Do you mean the exact value of pressure at which a touch becomes a force
> touch? The force/pressure threshold? Wonder if this could/should be defined
> simply as a property, like maxTouchPoints, but for
> forceTouchPressureThreshold or similar?
>
> (Btw, just to avoid confusion, I'm assuming you mean we should consider
> these sorts of events
> https://developer.apple.com/library/mac/documentation/AppleApplications/Conceptual/SafariJSProgTopics/RespondingtoForceTouchEventsfromJavaScript.html
> right?)
>
> I think that would stink - a
>> web dev should be able to just have code to handle a "force touch"
>> and get a consistent, interoperable experience across any OS and HW
>> platform combination that supports force touch capabilities.
>>
>> That being said, I can also imagine scenarios where a web dev would
>> want to control the haptic feedback aspects of force touch - at least
>> the ability to toggle it on and off.
>>
>
> I don't think the actual haptic feedback part is currently controllable
> (again just looking at the Apple documentation for force touch). Also
> wonder if this should be in scope for PE itself, rather than something like
> the vibrationAPI ?


The one thing you can do in Safari that you couldn't do at ALL (Ted's
concerns notwithstanding) is suppress the haptic feedback (IIRC you do this
in Safari by cancelling the webkitForceWillBegin event or something like
that).   Making that dependent on event cancellation seems like a poor
design IMHO - makes the haptics subject to arbitrary latency.  Instead a
PE-like model would be to use a CSS property to touch-action
("force-touch-action" maybe <grin>).

Ted, I don't think we should expend energy designing APIs for specific
hardware unless we can get discussion / feedback from the experts on that
hardware.  But if some sort of force-touch devices start shipping for other
platforms, then yes absolutely let's do it!  I'd just hate to define
something based on Apple's hardware, get no feedback from them, then see
other hardware in the market that invalidate some of our design assumptions
:-)

That said, if we're going to plumb through pressure on Mac OS, I'd be happy
to take the extra step as Patrick suggests of exposing some constant
properties to avoid developers hard-coding constants.  Would we want these
values on PointerEvent though?  Seems like InputDeviceCapabilities might be
a better fit.

I do not have any data to indicate that web developers are clamoring
>> for this and clearly anything that we were to specify would likely
>> only work on non-Safari browsers, but it is interesting to consider
>> nonetheless.
>>
>
> P
> --
> Patrick H. Lauke
> --
> Senior Accessibility Consultant
> The Paciello Group (UK office)
> https://www.paciellogroup.com
> --
> This message is intended to be confidential and may be legally
> privileged. It is intended solely for the addressee. If you are not the
> intended recipient, please delete this message from your system and
> notify us immediately. Any disclosure, copying, distribution or action
> taken or omitted to be taken by an unintended recipient in reliance on
> this message is prohibited and may be unlawful.
>
>