[webkit-help] Force Click events

Fri May 8 03:00:00 PDT 2015

On 2015-05-07 21:21, Benjamin Poulain wrote:
> Hi Jon,
>
> Beth does not participate on webkit-help. Can you move this discussion 
> to webkit-dev?
>
> I have one answer below. Beth can better answer the technical questions.
>
> On 5/7/15 1:17 AM, Jonathan Rimmer wrote:
>> On Twitter, I was bemoaning the lack of communication re. the recently
>> added Force Click events to Benjamin Poulain, and he suggested, probably
>> correctly, that I am out of the loop with respect to WebKit development.
>> There had, he said, been dicussion of this feature on the mailing lists,
>> bugzilla, and the recent contributors meeting.
>>
>> This therefore, is my attempt to get in the loop on this issue. I was
>> wondering if anyone could help me find the following:
>>
>> Mailing list posts: I have tried searching with the Gmane archive, but
>> have been unable to find any dicussions on this issue. It doesn't help
>> that Gmane does not support phrasal searches, meaning I cannot easily
>> search for "force click", "force touch", "pointer events", etc. Can
>> anyone suggest what words I should search for, or direct me to the
>> relevant threads?
>>
>> Contributors meeting: There was apparently a 1 hour discussion at the
>> contributor's meeting that lead to the agreement that the Force Click
>> experiment should be upstreamed. Is there a video or sound recording of
>> this dicussion available? Is there a set of minutes or other summary
>> available? A blog post?
>>
>> Documentation: Benjamin said the feature has been upstreamed to gather
>> feedback. Can anyone point me to developer documentation that would
>> assist in using/testing the feature? Or something like the Surfin'
>> Safari blog posts that introduced the CSS gradient feature?[1]
>>
>> I am also curious about the decision to develop a non-standard feature
>> instead of implementing Pointer Events? The Point Events spec defines a
>> "pressure" property on pointer events that seems analagous to the
>> "force" property introduced by this feature. Why was a proprietary
>> solution pursued instead of adopting the W3C standard? What does the
>> Force Click events offer that Pointer Events do not?
>
> You probably misunderstand what force click is. It is a second level 
> of click as you keep pressing on a trackpad (it is a "deeper" click). 
> The animations between the first and second clicks are driven by the 
> difference of pressure between the two.
>
> Pointer Events does not have any semantic that work with force click. 
> The "pressure" property on PointerEvent is pretty much useless in this 
> context.
>
> To make things worse, the way it was spec'ed does not correspond to 
> the way the hardware works.

I understand the purpose of force click, but what you're describing 
sounds like a subset of what pointer events provides. Force click 
provides a normalised 'force' property between 0 and 1, and pointer 
events provides a 'pressure' property between 0 and 1. Based on the 
event descriptions in the webkit bug, it seems like there is a mapping 
between the semantics of force click and the more general ones of 
pointer events:

webkitmouseforcewillbegin: pointerdown/pointermove with pressure 0.49

webkitmouseforcechanged: pointerdown/pointermove with pressure 0.5 
(regular click) or 1.0 (force click)

webkitmouseforcecancelled: pointerup after pointerdown/pointermove with 
pressure 0.49

webkitmouseforcedown: pointerdown/pointermove with pressure 1.0

webkitmouseforceup: pointermove with pressure 0 after previous 
pointermove with pressure 1.0

webkitmouseforceclick: pointerup after pointerdown/poitermove with 
pressure 1.0 on the same element.

It seems like a small JS library on-top of pointer events could easily 
have provided the force click semantics without needing an entirely new, 
and as yet non-standard, feature that is only supported by a single 
browser engine. If there are problems that I have missed, are they 
really so severe that no amount of enhancement or modification to the 
pointer events spec couldn't have addressed them?

I'm confused by your comments on the spec. Specs are developed in 
public, and vendors have an opportunity to contribute and provide 
feedback if they feel important use-cases are unaddressed or there are 
other problems with what is proposed. Many contributors to the Webkit 
project are also active in the W3C. Given the close alignment of the 
problem spaces covered by pointer events and force click, wouldn't it 
have been better to improve that specification than to develop an 
entirely new one? Particular one that is so tied to a particular 
implementation of pressure sensitive hardware?

Even if force click is eventually standardised, web developers such as 
myself face further complexity from supporting another type of input 
events, and further fragmentation of the web platform, with different 
browser supporting different standards. One of Webkit's stated goals is 
standards compliance. Disregarding existing specs to go your own way, 
and justifying it with post-hoc complaints about existing spec's 
deficiencies hardly seems in keeping with that goal.

>> Also, how does the development of this feature relate to the WebKit
>> project's stated goal of standards compliance? [2]. Is there a plan to
>> standardise this events with the W3C? Is it wise to name this feature
>> after a marketing term used by a single contributor organisation? Is it
>> intended that these features will be interopable with pressure-sensitive
>> hardware other than Apple's Force Touch trackpad?
>>
>> [1] https://www.webkit.org/blog/175/introducing-css-gradients/
>> [2] https://www.webkit.org/projects/goals.html
>>
>> Thanks,
>> Jon
>>
>>
>>
>> _______________________________________________
>> webkit-help mailing list
>> webkit-help at lists.webkit.org
>> https://lists.webkit.org/mailman/listinfo/webkit-help
>>
>