|
|
|
|
|
by nevir
5018 days ago
|
|
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. |
|