Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

From the spec: "The user agent must dispatch a pointercancel (and subsequently a pointerout event) whenever all of the following are true, in order to end the stream of events for the pointer:

The user agent has determined (via methods out of scope for this specification) that touch input is to be consumed for a touch behavior,"

Touch behaviours are things like scrolling, double-tap to zoom, pinch zoom.

The browser's double-tap to zoom gesture is at a lower level than the click event in the browser. As in, a double-tab will be consumed by the browser and never hit the page.



That precludes removing the delay, since that very delay is necessary to know whether it's a double tap.


Double-tap precludes the click event. But touch/pointer events can preclude the double-tap.


> But touch/pointer events can preclude the double-tap.

Your previous comment seems to imply otherwise: if the UA must dispatch pointercancel rather than pointerup on a double-tap, it has to wait until it can determine whether a double tap happened.


Omitting mouse & touch events, a tap goes: pointerdown, pointerup, click.

A double tap goes: pointerdown, pointercancel.

If the pointerdown event does event.preventDefault, it goes pointerdown, pointerdown.

The double-tap prevents the click. Preventing default in the pointerdown prevents the double-tap and also the click.


But that still means that the browser has to determine if it's a single tap or double tap before sending the pointerup, so it'll arrive after the 300ms delay.


No, it doesn't. The double tap gesture comes after pointer events. Pointer events can prevent double tap. Whereas click comes after the opportunity for double-tap, and double-tap will prevent click.

Try it in IE, or another browser using touch events.


> The double tap gesture comes after pointer events.

You make no sense, by your own description the double tap gesture changes what pointer events fire, pointerup can not fire until the UA knows for certain it's not going to be a doubletap, same as click.


If you don't trust me on this, that's fine. Test it for yourself.

Double tap does not change pointer events (https://dvcs.w3.org/hg/pointerevents/raw-file/tip/pointerEve...), they come first. But 'click' is not a pointer event, it's the result of some pointer events, and the lack of the browser doing something else, such as scrolling, double tap etc.

But seriously, don't take my word for it. Test it.


http://jsbin.com/IjerotI/1/quiet - here's a test for you. Try tapping, then double tapping on that page. See the difference in events.

This is touch events rather than pointer events, but the behaviour is similar. You can modify the test if you don't believe me.


> If you don't trust me on this, that's fine.

For the third time (might just be the charm), you contradict yourself, it's not that I don't trust you it's that you're internally inconsistent.


If I'm not explaining it properly, see the test and work it out yourself. Touch & pointer events happen before double tap (and can prevent it) click happens after all those and can be prevented.




Consider applying for YC's Summer 2026 batch! Applications are open till May 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: