Touch events on the mobile web are unfinished(plus.google.com)
plus.google.com
Touch events on the mobile web are unfinished
https://plus.google.com/106300407679257154689/posts/PBxtaphMDGJ
15 comments
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.
Microsoft's Windows 8 strategy gives me far more hope.
Hi, I work for Mozilla and I co-edited the W3C Touch Events standard. Some personal opinion follows...
Mozilla previously (before my time) did some work on multitouch events for early Windows touch PCs, but we don't have much influence in the mainstream mobile market because unlike other browser vendors we don't (yet) have our own mobile platform. In the current mobile market, Apple and Google have a lot of power to create de facto standards. It doesn't matter much if Mozilla evolves the API or creates our own alternative, unless the big mobile vendors agree to ship it too. (Google has participated in the Touch Events standardization process, but Apple has refused.) For example, Firefox is currently the only browser to implement some of the experimental features in the Touch Events spec, but that doesn't mean anyone will use them. Microsoft may have a chance of getting web developers to target a new API, but only because they can leverage Windows Phone and Windows 8.
The touch event standardization effort ground to a halt for much of the past year due to Apple (who is not participating in the working group) disclosing patents they claimed should block the standard. While work recently resumed, the future of touch events as an open standard is still cloudy.
With an existing de facto (but potentially non-open) standard, and an interesting (but non-standard) alternative already coming from Microsoft, the last thing we want is to further fork the platform by going off in our own, third direction. I would love to see Microsoft propose their Pointer Events API for standardization. That would provide a great way forward, and doing it within the W3C would let other vendors contribute, while requiring Microsoft and other participants (unlike Apple) to provide open licensing of any essential patents they hold. But without MS on board we would risk a repeat of the Apple patent issue. So for now it's partly a question of what Microsoft will do next.
In summary, I think we have some useful options, but realistically they depend on at least some of the mobile platform owners cooperating to move web standards forward.
Mozilla previously (before my time) did some work on multitouch events for early Windows touch PCs, but we don't have much influence in the mainstream mobile market because unlike other browser vendors we don't (yet) have our own mobile platform. In the current mobile market, Apple and Google have a lot of power to create de facto standards. It doesn't matter much if Mozilla evolves the API or creates our own alternative, unless the big mobile vendors agree to ship it too. (Google has participated in the Touch Events standardization process, but Apple has refused.) For example, Firefox is currently the only browser to implement some of the experimental features in the Touch Events spec, but that doesn't mean anyone will use them. Microsoft may have a chance of getting web developers to target a new API, but only because they can leverage Windows Phone and Windows 8.
The touch event standardization effort ground to a halt for much of the past year due to Apple (who is not participating in the working group) disclosing patents they claimed should block the standard. While work recently resumed, the future of touch events as an open standard is still cloudy.
With an existing de facto (but potentially non-open) standard, and an interesting (but non-standard) alternative already coming from Microsoft, the last thing we want is to further fork the platform by going off in our own, third direction. I would love to see Microsoft propose their Pointer Events API for standardization. That would provide a great way forward, and doing it within the W3C would let other vendors contribute, while requiring Microsoft and other participants (unlike Apple) to provide open licensing of any essential patents they hold. But without MS on board we would risk a repeat of the Apple patent issue. So for now it's partly a question of what Microsoft will do next.
In summary, I think we have some useful options, but realistically they depend on at least some of the mobile platform owners cooperating to move web standards forward.
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.
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.
Google wants people writing web apps. They're the big player in web ads. They don't have a similar advantage in mobile ads, especially on iOS. If web development creates better products easier than native development does, Google benefits.
For Apple this could very well be true, but Google also has an operating system (Chrome OS) that depends entirely on web applications. Although, to be fair, it doesn't ship on (m)any touch devices.
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.
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.
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.
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.
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.
I think taking a page from the native frameworks would be good here: Have a scroll start, scroll end, and nothing else. If you want to update during the scroll, you should be using requestAnimationFrame
What's wrong with throttled on-scroll?
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
You also don't know for sure when a scroll ends w/ the current impl
>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.
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.
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-use...
This is what excites me about something like Firefox OS (http://rawkes.com/articles/there-is-something-magical-about-...) -- 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.