- From: Patrick H. Lauke <redux@splintered.co.uk>
- Date: Wed, 24 Sep 2014 19:03:03 +0100
- To: "public-touchevents@w3.org" <public-touchevents@w3.org>, "public-pointer-events@w3.org" <public-pointer-events@w3.org>
On 24/09/2014 15:13, Rick Byers wrote: > Thanks Patrick! I confirm I see the same thing. Apparently I missed > this in my own testing of the beta build (too bad, I know they were > eager for feedback on any issues). It's easy to miss...who'd think that tapping for < 125ms and > 125ms would cause such different behavior... > The heuristic is an interesting one. I wonder how well 150ms > discriminates between taps in practice. We don't have great data on > this, but we do know that about half of all single-finger gestures on > Chrome complete in <150ms - so that suggests this isn't going to be a > big help to addressing the click delay problem on it's own. Purely subjectively, doing a "slow" tap - even just doing it for my test - feels ever so slightly too long and forced/unnatural. I had to be very deliberate in doing it. So yes, I doubt in practice this will have any perceivable effect / won't be good enough for devs to avoid implementing something more explicit like fastclick.js > The bug with touchend disposition being ignored is aweful! The old > Android browser used to ignore touchend dispositions and it was a huge > source of pain. Hopefully this is something they can fix quickly, it'll > be a real pain to work around (probably exacerbate the problem of sites > ignoring mouse events when touch events are supported). Please let us > know when you've filed the bug. Filed the bug (admittedly with a bit of polemic included, but hopefully it'll get some answers) https://bugs.webkit.org/show_bug.cgi?id=137069 P -- Patrick H. Lauke www.splintered.co.uk | https://github.com/patrickhlauke http://flickr.com/photos/redux/ | http://redux.deviantart.com twitter: @patrick_h_lauke | skype: patrick_h_lauke
Received on Wednesday, 24 September 2014 18:03:26 UTC