Contact emails
rby...@chromium.org, mus...@chromium.org
Target
Approval requested for M55.
Spec
https://w3c.github.io/pointerevents/
Summary
The Pointer Events API is a low-level input API for mouse, touch and stylus first introduced by Microsoft and then standardized in the W3C. The API extends the MouseEvent model to provide an input-modality-agnostic event handling mechanism, covering all uses of Mouse and Touch events.
Link to “Intent to Implement” blink-dev discussion
https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/ODWmcKNQl0I
Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
Yes.
Demo link
https://patrickhlauke.github.io/touch/
Debuggability
The PointerEvent API is already supported in devtools. In particular, console commands getEventListeners(), monitorEvents() and unmonitorEvents() already work for PointerEvents, and the debugging sidebar pane allows setting event listener breakpoints for any/all types of PointerEvents.
Interoperability and Compatibility Risk
IE/Edge: Public support (shipping since IE10)
Firefox: Public support (implementation in progress, available behind a flag)
Safari: Publicly opposed
Web developers: Mostly positive public support, including jQuery and Dojo.
Interoperability and compatibility risk is low because of following reasons.
While implementing, we have been actively engaged with the Pointer Events Working Group, particularly with Microsoft, to address all major technical issues. For all these issues, either we engaged other vendors to update their implementation & fix the spec accordingly, or changed our implementation to match the spec. At this point in time, we have only minor/futuristic spec issues to resolve. This close collaboration with the community helped us come to a consensus on a model for pointer, touch and mouse events that is highly interoperable between Edge, Chrome and Firefox, while remaining compatible with Safari’s implementation of touch and mouse events. Two major implementation issues have been resolved via breaking spec changes:
Although Pointer Events has pretty broad support for many years already, the lack of browser support (other than Edge) raised the bar high for early adaptation. Our usage stats suggests that ~1% of the pageviews use the API, and most of them use the API in an elementary (i.e. MouseEvent-like) manner. Our extensive manual compat testing both before & during the Implementation Hackathon with Microsoft, Mozilla & jQuery found no behavioral difference with Edge.
Chrome Canary and Dev channels have PointerEvents enabled (100%) via finch since M54. Chrome Beta and Chrome Stable will also have it enabled for respectively 50% and 1% of our users as M54 rolls out. We have found a few sites with bugs that are triggered when both touch and pointer events are supported, but these sites are similarly broken on Windows 10 Mobile. Many sites of this form that were broken in Edge are “fixed” by the removal of the ‘pointerEnabled’ API which was the original recommended way to feature detect for PointerEvents. We have not yet encountered any site that is broken as a result of the changes to the specification relative to what Edge has already shipped. If we encounter substantial breakage we’ll circle back with this thread before 55 hits stable.
OWP launch tracking bug
Entry on the feature dashboard
https://www.chromestatus.com/features/4504699138998272
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
tangentialPressure was added to the spec here:https://github.com/w3c/pointerevents/commit/efe7d4f6b891a2a3f53112ca9d7b262462465c2dI've logged crbug.com/649376 to ensure we have the definition in the IDLs.dave.On Thu, Sep 22, 2016 at 11:58 AM, Philip Jägenstedt <foo...@chromium.org> wrote:The work on interop and compat here is exemplary, thank you! How comprehensive is https://github.com/w3c/web-platform-tests/tree/master/pointerevents and do you know which tests are failing in which engines?I see that the PointerEvent interface has a tangentialPressure member in the spec but not in Blink, is this a recent addition to the spec?It is unusual to have another vendor publicly opposed. That was in 2012, has there been no public comment from WebKit developers since?
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
On Thu, Sep 22, 2016 at 11:58 AM, Philip Jägenstedt <foo...@chromium.org> wrote:The work on interop and compat here is exemplary, thank you! How comprehensive is https://github.com/w3c/web-platform-tests/tree/master/pointerevents and do you know which tests are failing in which engines?I see that the PointerEvent interface has a tangentialPressure member in the spec but not in Blink, is this a recent addition to the spec?It is unusual to have another vendor publicly opposed. That was in 2012, has there been no public comment from WebKit developers since?IIRC there have been a number of public (or semi-public) comments since then, but all of the form "we can't comment on pointer events" <grin>.Suffice it to say, I see no reason to believe that Apple will ever ship pointer events - but it's impossible to predict what could happen if there was sufficient developer demand. I.e. we're in the same state there that we were when we made the decision to restart our investments in PE. Personally I found this to be a tough trade-off (I of course care a LOT about Safari interop on mobile), but ultimately people succeeded in convincing me that it was important to have SOME healthy standards forum for evolving touch input on the web, and 3 out of 4 browsers participating in pointer events was better than roughly 1 (just us) publicly and actively participating in the touch events specification.
On Thu, Sep 22, 2016 at 5:39 PM Mustaq Ahmed <mus...@chromium.org> wrote:
[snip]
Interoperability and Compatibility Risk
IE/Edge: Public support (shipping since IE10)
Firefox: Public support (implementation in progress, available behind a flag)
Safari: Publicly opposed
Web developers: Mostly positive public support, including jQuery and Dojo.
Interoperability and compatibility risk is low because of following reasons.
While implementing, we have been actively engaged with the Pointer Events Working Group, particularly with Microsoft, to address all major technical issues. For all these issues, either we engaged other vendors to update their implementation & fix the spec accordingly, or changed our implementation to match the spec. At this point in time, we have only minor/futuristic spec issues to resolve. This close collaboration with the community helped us come to a consensus on a model for pointer, touch and mouse events that is highly interoperable between Edge, Chrome and Firefox, while remaining compatible with Safari’s implementation of touch and mouse events. Two major implementation issues have been resolved via breaking spec changes:
Although Pointer Events has pretty broad support for many years already, the lack of browser support (other than Edge) raised the bar high for early adaptation. Our usage stats suggests that ~1% of the pageviews use the API, and most of them use the API in an elementary (i.e. MouseEvent-like) manner. Our extensive manual compat testing both before & during the Implementation Hackathon with Microsoft, Mozilla & jQuery found no behavioral difference with Edge.
Chrome Canary and Dev channels have PointerEvents enabled (100%) via finch since M54. Chrome Beta and Chrome Stable will also have it enabled for respectively 50% and 1% of our users as M54 rolls out. We have found a few sites with bugs that are triggered when both touch and pointer events are supported, but these sites are similarly broken on Windows 10 Mobile. Many sites of this form that were broken in Edge are “fixed” by the removal of the ‘pointerEnabled’ API which was the original recommended way to feature detect for PointerEvents. We have not yet encountered any site that is broken as a result of the changes to the specification relative to what Edge has already shipped. If we encounter substantial breakage we’ll circle back with this thread before 55 hits stable.
My LGTM still stands, but a question: what's the status of avoiding hit testing on pointer move? I assume our implementation avoids it; will Edge follow suit? Any interesting performance examples to share showingimproved performance over touch APIs?
lgtm3 fwiw
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
Super excited about this. Nice work, all.On Thu, Sep 22, 2016 at 6:23 PM, Jochen Eisinger <joc...@chromium.org> wrote:lgtm3 fwiwOn Thu, Sep 22, 2016 at 6:19 PM Chris Harrelson <chri...@chromium.org> wrote:My LGTM still stands, but a question: what's the status of avoiding hit testing on pointer move? I assume our implementation avoids it; will Edge follow suit? Any interesting performance examples to share showingimproved performance over touch APIs?
On Thu, Sep 22, 2016 at 5:08 PM, 'Dave Tapuska' via blink-dev <blin...@chromium.org> wrote:tangentialPressure was added to the spec here:https://github.com/w3c/pointerevents/commit/efe7d4f6b891a2a3f53112ca9d7b262462465c2dI've logged crbug.com/649376 to ensure we have the definition in the IDLs.dave.On Thu, Sep 22, 2016 at 11:58 AM, Philip Jägenstedt <foo...@chromium.org> wrote:The work on interop and compat here is exemplary, thank you! How comprehensive is https://github.com/w3c/web-platform-tests/tree/master/pointerevents and do you know which tests are failing in which engines?I see that the PointerEvent interface has a tangentialPressure member in the spec but not in Blink, is this a recent addition to the spec?It is unusual to have another vendor publicly opposed. That was in 2012, has there been no public comment from WebKit developers since?IIRC there have been a number of public (or semi-public) comments since then, but all of the form "we can't comment on pointer events" <grin>.Suffice it to say, I see no reason to believe that Apple will ever ship pointer events - but it's impossible to predict what could happen if there was sufficient developer demand. I.e. we're in the same state there that we were when we made the decision to restart our investments in PE. Personally I found this to be a tough trade-off (I of course care a LOT about Safari interop on mobile), but ultimately people succeeded in convincing me that it was important to have SOME healthy standards forum for evolving touch input on the web, and 3 out of 4 browsers participating in pointer events was better than roughly 1 (just us) publicly and actively participating in the touch events specification.
On Thu, Sep 22, 2016 at 11:58 AM, Philip Jägenstedt <foo...@chromium.org> wrote:The work on interop and compat here is exemplary, thank you! How comprehensive is https://github.com/w3c/web-platform-tests/tree/master/pointerevents and do you know which tests are failing in which engines?I see that the PointerEvent interface has a tangentialPressure member in the spec but not in Blink, is this a recent addition to the spec?It is unusual to have another vendor publicly opposed. That was in 2012, has there been no public comment from WebKit developers since?IIRC there have been a number of public (or semi-public) comments since then, but all of the form "we can't comment on pointer events" <grin>.Suffice it to say, I see no reason to believe that Apple will ever ship pointer events - but it's impossible to predict what could happen if there was sufficient developer demand. I.e. we're in the same state there that we were when we made the decision to restart our investments in PE. Personally I found this to be a tough trade-off (I of course care a LOT about Safari interop on mobile), but ultimately people succeeded in convincing me that it was important to have SOME healthy standards forum for evolving touch input on the web, and 3 out of 4 browsers participating in pointer events was better than roughly 1 (just us) publicly and actively participating in the touch events specification.
On Thu, Sep 22, 2016 at 5:39 PM Mustaq Ahmed <mus...@chromium.org> wrote:
[snip]
Interoperability and Compatibility Risk
IE/Edge: Public support (shipping since IE10)
Firefox: Public support (implementation in progress, available behind a flag)
Safari: Publicly opposed
Web developers: Mostly positive public support, including jQuery and Dojo.
Interoperability and compatibility risk is low because of following reasons.
While implementing, we have been actively engaged with the Pointer Events Working Group, particularly with Microsoft, to address all major technical issues. For all these issues, either we engaged other vendors to update their implementation & fix the spec accordingly, or changed our implementation to match the spec. At this point in time, we have only minor/futuristic spec issues to resolve. This close collaboration with the community helped us come to a consensus on a model for pointer, touch and mouse events that is highly interoperable between Edge, Chrome and Firefox, while remaining compatible with Safari’s implementation of touch and mouse events. Two major implementation issues have been resolved via breaking spec changes:
Although Pointer Events has pretty broad support for many years already, the lack of browser support (other than Edge) raised the bar high for early adaptation. Our usage stats suggests that ~1% of the pageviews use the API, and most of them use the API in an elementary (i.e. MouseEvent-like) manner. Our extensive manual compat testing both before & during the Implementation Hackathon with Microsoft, Mozilla & jQuery found no behavioral difference with Edge.
Chrome Canary and Dev channels have PointerEvents enabled (100%) via finch since M54. Chrome Beta and Chrome Stable will also have it enabled for respectively 50% and 1% of our users as M54 rolls out. We have found a few sites with bugs that are triggered when both touch and pointer events are supported, but these sites are similarly broken on Windows 10 Mobile. Many sites of this form that were broken in Edge are “fixed” by the removal of the ‘pointerEnabled’ API which was the original recommended way to feature detect for PointerEvents. We have not yet encountered any site that is broken as a result of the changes to the specification relative to what Edge has already shipped. If we encounter substantial breakage we’ll circle back with this thread before 55 hits stable.
My LGTM still stands, but a question: what's the status of avoiding hit testing on pointer move? I assume our implementation avoids it; will Edge follow suit? Any interesting performance examples to share showingimproved performance over touch APIs?
Ted from Microsoft Edge here.
As Rick mentioned, our intention right now is that we will ship with implicit capture for touch ON by default, which means no hit testing on pointer move and not firing boundary events. There will be a flag to revert this behavior, although that part has not yet been implemented. There is a current bug on Edge that we are tracking regarding an event ordering difference between Chrome and Edge – it is unclear right now whether it would be an interoperability issue or not.
At this point, the Edge implementation will continue to hit test and send boundary events when a developer explicitly calls SetPointerCapture. We are involved with the discussion that Rick mentioned to come to consensus on the best behavior for explicit capture.
Ted
1. While implementing, we have been actively engaged with the Pointer Events Working Group, particularly with Microsoft, to address all major technical issues. For all these issues, either we engaged other vendors to update their implementation & fix the spec accordingly, or changed our implementation to match the spec. At this point in time, we have only minor/futuristic spec issues to resolve. This close collaboration with the community helped us come to a consensus on a model for pointer, touch and mouse events that is highly interoperable between Edge, Chrome and Firefox, while remaining compatible with Safari’s implementation of touch and mouse events. Two major implementation issues have been resolved via breaking spec changes:
a. Implicit Capture for touch is enabled by default, and
b. Boundary Events are not sent during capturing.
2. Although Pointer Events has pretty broad support for many years already, the lack of browser support (other than Edge) raised the bar high for early adaptation. Our usage stats suggests that ~1% of the pageviews use the API, and most of them use the API in an elementary (i.e. MouseEvent-like) manner. Our extensive manual compat testing both before & during the Implementation Hackathon with Microsoft, Mozilla & jQuery found no behavioral difference with Edge.
3. Chrome Canary and Dev channels have PointerEvents enabled (100%) via finch since M54. Chrome Beta and Chrome Stable will also have it enabled for respectively 50% and 1% of our users as M54 rolls out. We have found a few sites with bugs that are triggered when both touch and pointer events are supported, but these sites are similarly broken on Windows 10 Mobile. Many sites of this form that were broken in Edge are “fixed” by the removal of the ‘pointerEnabled’ API which was the original recommended way to feature detect for PointerEvents. We have not yet encountered any site that is broken as a result of the changes to the specification relative to what Edge has already shipped. If we encounter substantial breakage we’ll circle back with this thread before 55 hits stable.
I added Ted who's driving the implementation these days in Edge. I believe they're working on all the minor differences identified here, in particular #1. I think he has a build he is demo'ing at TPAC that demonstrates interoperability with these changes implemented. We'll of course monitor compat impact as we roll this out in preview builds. But I don't personally anticipate any major issues here.
On Thursday, September 22, 2016 at 10:19:09 AM UTC-7, Chris Harrelson wrote:
My LGTM still stands, but a question: what's the status of avoiding hit testing on pointer move? I assume our implementation avoids it; will Edge follow suit? Any interesting performance examples to share showing
improved performance over touch APIs?
Yes, we're making the changes detailed in #1 above to align on avoiding hit testing on pointer move in Edge. Ted can comment further on our progress there. I expect we'll see preview builds with this in the coming weeks/months at least under a flag.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
☆PhistucK
☆PhistucK
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/e308b39b-4b66-637d-e8fe-83170956045b%40welho.com.
Helouu can somebody help me please ? , I'm waiting for answering thanks guys :)
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/e308b39b-4b66-637d-e8fe-83170956045b%40welho.com.
Contact emails
rby...@chromium.org, mus...@chromium.org
Target
Approval requested for M55.
Spec
https://w3c.github.io/pointerevents/
Summary
The Pointer Events API is a low-level input API for mouse, touch and stylus first introduced by Microsoft and then standardized in the W3C. The API extends the MouseEvent model to provide an input-modality-agnostic event handling mechanism, covering all uses of Mouse and Touch events.
Link to “Intent to Implement” blink-dev discussion
https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/ODWmcKNQl0I
Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
Yes.
Demo link
https://patrickhlauke.github.io/touch/
Debuggability
The PointerEvent API is already supported in devtools. In particular, console commands getEventListeners(), monitorEvents() and unmonitorEvents() already work for PointerEvents, and the debugging sidebar pane allows setting event listener breakpoints for any/all types of PointerEvents.
Interoperability and Compatibility Risk
IE/Edge: Public support (shipping since IE10)
Firefox: Public support (implementation in progress, available behind a flag)
Safari: Publicly opposed
Web developers: Mostly positive public support, including jQuery and Dojo.
Interoperability and compatibility risk is low because of following reasons.
While implementing, we have been actively engaged with the Pointer Events Working Group, particularly with Microsoft, to address all major technical issues. For all these issues, either we engaged other vendors to update their implementation & fix the spec accordingly, or changed our implementation to match the spec. At this point in time, we have only minor/futuristic spec issues to resolve. This close collaboration with the community helped us come to a consensus on a model for pointer, touch and mouse events that is highly interoperable between Edge, Chrome and Firefox, while remaining compatible with Safari’s implementation of touch and mouse events. Two major implementation issues have been resolved via breaking spec changes:
Although Pointer Events has pretty broad support for many years already, the lack of browser support (other than Edge) raised the bar high for early adaptation. Our usage stats suggests that ~1% of the pageviews use the API, and most of them use the API in an elementary (i.e. MouseEvent-like) manner. Our extensive manual compat testing both before & during the Implementation Hackathon with Microsoft, Mozilla & jQuery found no behavioral difference with Edge.
Chrome Canary and Dev channels have PointerEvents enabled (100%) via finch since M54. Chrome Beta and Chrome Stable will also have it enabled for respectively 50% and 1% of our users as M54 rolls out. We have found a few sites with bugs that are triggered when both touch and pointer events are supported, but these sites are similarly broken on Windows 10 Mobile. Many sites of this form that were broken in Edge are “fixed” by the removal of the ‘pointerEnabled’ API which was the original recommended way to feature detect for PointerEvents. We have not yet encountered any site that is broken as a result of the changes to the specification relative to what Edge has already shipped. If we encounter substantial breakage we’ll circle back with this thread before 55 hits stable.
On 12/21/19 12:48 AM, PhistucK wrote:
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/e308b39b-4b66-637d-e8fe-83170956045b%40welho.com.