-
Notifications
You must be signed in to change notification settings - Fork 27
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Pointer events #15
Comments
This is an feature where we see a relatively large number of developer-filed bug reports, indicating that it's something that people run into when creating sites (e.g. https://bugzilla.mozilla.org/show_bug.cgi?id=1529904, https://bugzilla.mozilla.org/show_bug.cgi?id=1675846, https://bugzilla.mozilla.org/show_bug.cgi?id=1695574) so I agree that this makes sense as a focus area. |
Note that Safari doesn't support touch events on macOS (the only platform on wpt.fyi), because macOS doesn't support touch input, as such I think we'd be opposed to including the touch action tests in this bracket. (Not making any statement about the inclusion of the rest of pointer events, just noting that there is that limitation.) |
Wouldn't touch action tests get ignored for MacOS then? |
Currently they result in failures, but it could be a good goal to update the tests so that lack of touch support on the platform skips the tests. |
Looking at https://wpt.fyi/results/pointerevents?label=master&label=experimental&product=chrome&product=firefox&product=safari&aligned, some touch tests are easy to exclude, like any that have "touch" in the test name. More problematic are any tests that use touch but don't strictly have to. In particular, test using @flackr would you be able to make a list of tests that would work without touch support, and see if that's still enough to be useful? |
@mustaqahmed Do you think you could help with this? |
Looking at https://wpt.fyi/results/pointerevents/idlharness.window.html?label=master&label=experimental&product=chrome&product=firefox&product=safari&aligned&q=%21touch%20%21pen (i.e., excluding both touch and pen) we see much more green than the overall summary. Looking at idlharness:
Of the above query, it seems that:
Given that, I guess the question in part becomes "do we want to exclude any tests/features that fail in two browsers?". |
Per #39 (comment) we won't include this in Interop 2022, but before closing it we should figure out if there's something here we want to work jointly on in 2022. @gsnedders can you elaborate on "WPT coverage does not seem representative of site compatibility bugs"? What kinds of site compat issues you tend to see with Pointer Events? Perhaps focusing on those aspects would put this in better shape for Interop 2023. |
Looking at bugs.webkit.org shows a variety of issues; these are:
|
so checking mozilla webcompat issues related to pointer events.
|
Is this something where a different WebKit port might enable the feature on desktop, and provide a useful proxy for iOS Safari? Or is there a lot of port-specific code? |
Closing this, discussion continues in https://github.com/web-platform-tests/interop-2022-pointer. |
Description
The pointerevents spec provides a unified input model for handling pointing devices regardless of their type (e.g. mouse, touch, stylus) and contains many new capabilities to these events such as predicted points and pointer capture.
Specification
https://w3c.github.io/pointerevents/
Tests
Links to web-platform-tests (on https://wpt.fyi) for the feature:
https://wpt.fyi/results/pointerevents?label=master&label=experimental&aligned
Rationale
The pointerevents spec is where new input features are arriving and developers using pointerevents instead of mouse or touch event listeners improves usability across input modalities. Additionally, using touch-action and passive event listeners improves scrolling performance. However, differences in behavior can lead to adoption or usability issues.
The text was updated successfully, but these errors were encountered: