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

Could we ever do implicit capture for all pointer types? #125

Open
RByers opened this Issue Jul 29, 2016 · 12 comments

Comments

Projects
None yet
6 participants
@RByers
Contributor

RByers commented Jul 29, 2016

In #8 we're discussing doing implicit capture for touch. At the hackathon we discussed the "crazy" idea of doing implicit capture for all pointer types and agreed it would almost certainly be too breaking to change long-standing mouse event behavior (and any other option we could think of would be fraught with problems).

But I'm still wondering if there might still be some long-term path here (i.e. not something I'd want to couple to shipping pointer events in Chrome in the first place, but a possible transition later).

To help provide some data on this question @scottgonzalez wrote this Chrome extension. You can try it out by using the "download zip" option in GitHub, unzip to a folder, then "load unpacked extension" in chrome://extensions. After a few minutes of playing on major sites I haven't yet found an issue. I'm sure there's tons of breakage out there, but still maybe it's not as intractable as we thought?

Note that Chrome doesn't yet alter hit-testing during capture for mouse - only for touch. So this isn't a complete test.

One thing that would break for sure is :hover styles during dragging, but maybe some rationalization will come out of #123 that would help.

Long term, if we imagine a world where >80% of web usage is via a phone (we're already at >50% by many measures) then maybe eventually changing the long-standing model of mouse isn't entirely insane?

@patrickhlauke

This comment has been minimized.

Show comment
Hide comment
@patrickhlauke

patrickhlauke Jul 29, 2016

Member

not tried the extension, but: would this sort of thing not break UA behavior like dragging a link to the desktop on windows to create a shortcut and similar?

Member

patrickhlauke commented Jul 29, 2016

not tried the extension, but: would this sort of thing not break UA behavior like dragging a link to the desktop on windows to create a shortcut and similar?

@RByers

This comment has been minimized.

Show comment
Hide comment
@RByers

RByers Jul 29, 2016

Contributor

Not necessarily, I think we could have the built-in drag-and-drop still work when captured. More challenging is perhaps HTML5 DnD APIs. That appears to still work with the extension, but probably only because we still have the boundary events (not yet modifying hit-test during capture for mouse).

Here's one possible compromise that's more rational that the touch/mouse split. We could state that drag and drop has the effect of releasing pointer capture (although we'd have to specify that this is ALL dragging as triggered as the default action of mousedown, not just HTML5 DnD where elements opt-in with draggable). Then mouse dragging by default would not be captured (but would be if you preventDefault the mousedown), but touch would be.

Contributor

RByers commented Jul 29, 2016

Not necessarily, I think we could have the built-in drag-and-drop still work when captured. More challenging is perhaps HTML5 DnD APIs. That appears to still work with the extension, but probably only because we still have the boundary events (not yet modifying hit-test during capture for mouse).

Here's one possible compromise that's more rational that the touch/mouse split. We could state that drag and drop has the effect of releasing pointer capture (although we'd have to specify that this is ALL dragging as triggered as the default action of mousedown, not just HTML5 DnD where elements opt-in with draggable). Then mouse dragging by default would not be captured (but would be if you preventDefault the mousedown), but touch would be.

@teddink

This comment has been minimized.

Show comment
Hide comment
@teddink

teddink Jul 29, 2016

We would have to do the same for touch drag and drop as well - Edge now support touch based cross process drag and drop as well.

teddink commented Jul 29, 2016

We would have to do the same for touch drag and drop as well - Edge now support touch based cross process drag and drop as well.

@RByers

This comment has been minimized.

Show comment
Hide comment
@RByers

RByers Jul 29, 2016

Contributor

Yep but you need a long press gesture to trigger that, right? Just dragging with touch is not enough to trigger drag and drop.

Contributor

RByers commented Jul 29, 2016

Yep but you need a long press gesture to trigger that, right? Just dragging with touch is not enough to trigger drag and drop.

@teddink

This comment has been minimized.

Show comment
Hide comment
@teddink

teddink Jul 29, 2016

Yep - true enough - long press is needed before the draggable item is "captured" to the touch point for dragging.

teddink commented Jul 29, 2016

Yep - true enough - long press is needed before the draggable item is "captured" to the touch point for dragging.

@NavidZ

This comment has been minimized.

Show comment
Hide comment
@NavidZ

NavidZ Oct 20, 2016

Member

Is it safe to give up on this idea because of the mouse event impact?

Member

NavidZ commented Oct 20, 2016

Is it safe to give up on this idea because of the mouse event impact?

@patrickhlauke

This comment has been minimized.

Show comment
Hide comment
@patrickhlauke

patrickhlauke Oct 20, 2016

Member

Is it safe to give up on this idea because of the mouse event impact?

Personally, I think so, yes

Member

patrickhlauke commented Oct 20, 2016

Is it safe to give up on this idea because of the mouse event impact?

Personally, I think so, yes

@scottgonzalez

This comment has been minimized.

Show comment
Hide comment
@scottgonzalez

scottgonzalez Oct 20, 2016

Member

😢 I'll hold on to my dreams that one day this will happen...

Member

scottgonzalez commented Oct 20, 2016

😢 I'll hold on to my dreams that one day this will happen...

@RByers

This comment has been minimized.

Show comment
Hide comment
@RByers

RByers Oct 27, 2016

Contributor

Personally I was shocked that I didn't come across a single site impacted by this by running with Scott's extension enabled for a month or so. Maybe it's not so hopeless? Or at least if we're going to close it, we should perhaps have at least ONE example of a real-world website that's significantly broken by it? Thoughts?

Regardless it's definitely NOT v2 - more crazy idea to consider for the future.

Contributor

RByers commented Oct 27, 2016

Personally I was shocked that I didn't come across a single site impacted by this by running with Scott's extension enabled for a month or so. Maybe it's not so hopeless? Or at least if we're going to close it, we should perhaps have at least ONE example of a real-world website that's significantly broken by it? Thoughts?

Regardless it's definitely NOT v2 - more crazy idea to consider for the future.

@RByers RByers reopened this Oct 27, 2016

@mustaqahmed

This comment has been minimized.

Show comment
Hide comment
@mustaqahmed

mustaqahmed Oct 27, 2016

Contributor

You are right: without a concrete example of a broken site, I shouldn't have closed the issue. Even though we agreed during the hackathon that the risk seems big, we also agreed that a pointer-type-independent behavior would be a great.

Contributor

mustaqahmed commented Oct 27, 2016

You are right: without a concrete example of a broken site, I shouldn't have closed the issue. Even though we agreed during the hackathon that the risk seems big, we also agreed that a pointer-type-independent behavior would be a great.

@patrickhlauke

This comment has been minimized.

Show comment
Hide comment
@patrickhlauke

patrickhlauke Nov 8, 2016

Member

Coming back to this, what about a non-normative note that gives UAs the freedom to choose to do this if they want (i.e. that it's up to the implementations)? Or is that too lax?

Member

patrickhlauke commented Nov 8, 2016

Coming back to this, what about a non-normative note that gives UAs the freedom to choose to do this if they want (i.e. that it's up to the implementations)? Or is that too lax?

@patrickhlauke patrickhlauke added bug question and removed bug labels Feb 9, 2018

@NavidZ NavidZ added the future-v3 label Mar 28, 2018

@NavidZ

This comment has been minimized.

Show comment
Hide comment
@NavidZ

NavidZ Mar 28, 2018

Member

We talked about this issue in the call and decided that we like to have such a feature. But since there might be some compat issues (as observed by the Chrome extension and some Gmail labels) we need to take more time and move more slowly for this.

Member

NavidZ commented Mar 28, 2018

We talked about this issue in the call and decided that we like to have such a feature. But since there might be some compat issues (as observed by the Chrome extension and some Gmail labels) we need to take more time and move more slowly for this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment