Scrollability
joehewitt.github.com
joehewitt.github.com
11:55 AM: "I feel suddenly motivated to write a tiny JS library that does scrolling right, or at least as close as possible."
10:20 PM: "I think we're ready to demo."
Now that's gumption.
Insofar as Apple continues to invest in UI R&D, a clone of their UI's look and feel will always lack fidelity to the original, sit in the uncanny valley when approached by users, and require ongoing maintenance to track upstream changes as best as possible.
Additionally, fluid scrolling on iOS devices is resource intensive and requires a very careful attention to performance details; I've yet to see HTML5 UIs scroll as smoothly as a tuned native UI.
No, web components haven't met native ones yet, but they only need to achieve 60 fps. They will get there, it's a safe bet.
> Broadly speaking, investment in mobile webapps largely seems to be about improving the entrenched web developer's experience, rather than the actual user's experience.
While there is some truth to this, it doesn't tell the whole story. Most developers don't have the time or desire to maintain multiple native codebases, and so using web tools improves user experience by allowing the app to exist on their platform at all. Also, sometimes these things come in handy on actual websites (personally, I consider "Click here to download our mobile app!" terrible UX).
The problem is that it uses CSS that works only in WebKit, but does not fall back gracefully in any other browser. It depends on CSS3 2D Transforms. Because the 2D Transforms spec is not yet a Candidate Recommendation, browser vendors currently implement it with vendor prefixes in case the spec changes before it's finalized. 2D Transforms are implemented in recent versions of IE (-ms-transform), Opera (-o-transform), Gecko (-moz-transform), and WebKit (-webkit-transform). However, the library uses only -webkit-transform.
That wouldn't be so bad, except that it does this in a way that potentially breaks the page in other browsers. For example, mobile Firefox supports overflow scrolling without any need for libraries. In the latest nightly builds of mobile Firefox 6 (which support touch events), adding iscroll.js to your page will actually break scrollable elements that work fine without the library.
The solution is two-fold: (1) If you are using vendor-prefixed APIs you can easily support more implementations, and (2) do feature detection to fail gracefully on implementations that you don't support. And yes, I plan to submit patches to these projects to address these problems.
(disclosure: I am a mobile Firefox developer)
The -webkit-transform: translate3d(0,x,y) (3D, not 2D transforms) property forces the element to be hardware accelerated under mobile safari, without this, the redraw would be around 10 times slower. This is the whole point of the library (hacking around a known issue in mobile safari)
Besides, he states that the code requires iOS. It is not a mistake to include vendor specific code in this way when targeting a specific platform for optimisation.
The best thing he could do is work with others. Not go all lone wolf on the very people he said he wanted to help.
As an aside, I think that github might be able to help a lot with encouraging collaboration in light of so many duplicate projects by working on better ways to discover projects (either by better search indexing, better SEO or otherwise). And as a disclaimer: I think github is one of the most innovative companies today, so this is by no means an attempt to point fingers, rather an observation that they have a huge opportunity to really change how OSS works.
apologizing for my ignorance, does anyone know for sure why these libraries are necessary? it seems like it wouldn't be hard to offer a standard way (or even a meta tag, i appreciate that pinch zooming is a reasonable default) to get smooth accelerated scrolling of fixed and/or overflow:auto containers.
Even if they do, libraries like these may still be necessary for more advanced scrolling mechanisms like those that snap to page boundaries or involve scrolling/zooming hybrids (like photo viewers common to many apps).
i'm sure i speak for a lot of people when i say thanks for working to advance the prospect of truly first-class web applications on mobile. these are exciting times!
This is what overflow-scrollable areas on webpages should have been in iOS Safari. At the moment you have to mash two fingers into the screen and slowly drag it around; real clunky.
Fingers crossed (badum-tish) for an update next month.
With the swarm of crappy alternatives - barely mimicking the native behaviour - I saw before I was giving up on the hope that something like this could even remotely exist.
PS, yes, I'm that Koush of Android. I'm a little opinionated when it comes to mobile development. :)
Anyway, the current code is trying to replicate the feel of iOS scrolling. An Android implementation should try to replicate the feel of Android scrolling, which is much different. I will get around to it...
Web apps are hacks.
There are a lot of native apps that are easily reproduced in pure HTML, CSS and Javascript.
Just like everything else: use the right tool for the job, and choose your trade-offs.
either way i can't imagine that an iOS monoculture in high-end mobile applications really serves anyone but apple in the long run. i think there's a general consensus that it didn't work out that well with windows, and there's arguably a lot more at stake this time.