- From: Mustaq Ahmed via GitHub <sysbot+gh@w3.org>
- Date: Mon, 15 May 2017 17:26:38 +0000
- To: public-pointer-events@w3.org
One key advantage of PointerEvents is that default actions are never blocked on script execution, to guarantee responsive browser behavior even with a slow script. This essentially means a script has less granular control over browser actions (vs TouchEvents): either the script declares beforehand (though `touch-action`) that it wants to handle the input event stream itself, or it has to take over the control at `pointerdown`. After the `pointerdown`, browser can take over the control anytime (but must let the script know through a `pointercancel`). The drag action as the default action of `pointerdown` fits the model perfectly. I have no strong opinion on whether the `pointercancel` should be before or after the `dragstart`; I am slightly biased towards "before". > What if there is a clickable element, like a <button>, in the draggable container? I would want the user to be able to click on it if they don't move their cursor but to drag the container if they do. Same concept here: a script cannot delay a browser action until `pointermove`, it's too late to guarantee responsiveness. E.g. consider what would happen if the script is super slow in `pointerdown`. > Similarly, imagine a carousel that pans left/right. If the user drags left/right, my JS event listener ought to drag the carousel to show the next image. If the user drags up/down, the page ought to scroll (the browser default). In pointerdown, I don't have enough information to know if I should prevent the default behavior. In this case, the page can limit browser's control to vertical panning only, though `touch-action: pan-y`. -- GitHub Notification of comment by mustaqahmed Please view or discuss this issue at https://github.com/w3c/pointerevents/issues/205#issuecomment-301544136 using your GitHub account
Received on Monday, 15 May 2017 17:26:45 UTC