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@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-help
_______________________________________________
webkit-help mailing list
webkit-help@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-help
