

Touch events on the mobile web are unfinished - maccman
https://plus.google.com/106300407679257154689/posts/PBxtaphMDGJ

======
gkoberger
Apple and Google have no incentive to perfect this. They want people writing
native apps.

This is what excites me about something like Firefox OS
([http://rawkes.com/articles/there-is-something-magical-
about-...](http://rawkes.com/articles/there-is-something-magical-about-
firefox-os)) -- Mozilla has the incentive to make mobile apps a first class
citizen. If JavaScript/CSS/HTML is "native", then they have no choice but to
get it right.

Plus, when it comes to standards, Mozilla already has a foot in the door.

~~~
wycats
If this was true, I'd expect Mozilla to be pushing this forward. Instead, we
have Apple's native scroll solution and Microsoft's Pointer API. Neither is
perfect, but frankly Mozilla is not leading on this.

Microsoft's Windows 8 strategy gives me far more hope.

~~~
MatthewPhillips
This is mostly a WebKit problem. In IE10/Windows 8 you can and should listen
for click when you want a click, not pointerup. Making click events fire slow
was a major design mistake by WebKit. It is not an issue in Win8.

~~~
wycats
I don't agree, and I explain why in the OP. Unless Microsoft perfectly handles
scrolling/click in their implementation, this solution won't work.

------
tmanderson
What's the deal with these posts? First the one from Facebook and now this
one?

If it's too hard for you to differentiate between a scroll and a touch,
there's about 210923423234 libraries out there that can make that
differentiation for you.

~~~
nevir
There's a significant amount of effort put into touch handling on the native
side of the world. Browser-based apps shouldn't be in the business of
emulating the native behavior unless absolutely necessary. (Unfortunately,
it's painfully frequent atm)

You encounter difficulties such as:

* Different behavior across platforms (and risking uncanny valley responses if you don't duplicate it; particularly around scrolling)

* When the browser provides hooks into the underlying native code, the current event structure can't satisfy. For example, `-webkit-overflow-scrolling: touch` fires scroll events erratically on iOS and fails to update the scroll position between them.

* Fun "bugs" such as iOS Safari's annoying behavior of popping down the nav bar when you tap any anchor that has a href attribute - _regardless_ of whether you intercept and cancel the events in either phase.

It's a matter of finding a balance between abstracting platforms and simply
exposing their underlying mechanics. I'm not sure which side should win there.

------
MatthewPhillips
Another high-level event we need is scroll-end, or better, scroll-to-end. On
scroll is very expensive on mobile and leads to lagginess.

~~~
mistercow
What's wrong with throttled on-scroll?

~~~
nevir
You can't do smart things on each frame (for ex, subbing in new content as the
user scrolls)

You also don't know for sure when a scroll ends w/ the current impl

~~~
mistercow
>You can't do smart things on each frame (for ex, subbing in new content as
the user scrolls)

You wouldn't be able to do that with scroll-end either.

>You also don't know for sure when a scroll ends w/ the current impl

That makes sense, but that issue is orthogonal to performance.

------
huskyr
If you're getting tired of all the useless UI when reading Google Plus posts
too, i've written a smal Userscript to remove it:

[http://www.haykranen.nl/2012/09/16/a-simple-greasemonkey-
use...](http://www.haykranen.nl/2012/09/16/a-simple-greasemonkey-userscript-
to-remove-all-google-plus-ui/)

