One of the most important features has been finally added to iScroll: please welcome the snap scroll. The scrolling area is subdivided into pages and you may choose to scroll to any page both programmatically and with user swipes. The code has been further optimized so that the new feature doesn’t impact on file size nor performance.
The most requested feature for iScroll was probably the ability to programmatically scroll to an element by #id. v3.5 adds this feature and much more. You can actually scroll to any element from a CSS3 query selector opening the door to hardware accelerated carousels.
Frameworks for mobile platforms are coming out quickly. What was pioneering not more than two months ago is now everybody’s land. In this scenario does it still make sense to develop stand alone scripts like iScroll? Short answer: yes.
This latest update brings even better Android compatibility. If I receive no complains I’d consider this release final, freeze the code and move to the next milestone (3.4).
If you use iScroll or any web app that takes advantage of touch events you’ll sooner or later stumble in an annoying bug: when you swipe over the bottom browser bar the touchend event is not fired and the application freezes. Here I’m trying to explain why this happens and how to fix it.
Android is a bad beast but we’ll tame it. My quest to get full Android compatibility continues and this time we are getting pretty close to it. Once again I need beta testers!
You asked for it and now you have it. v3.3 (beta 1) is my first attempt to port iScroll to Android 1.5. It seems to work, but no hardware acceleration. Is it really worth the effort?
I’m surprised to see that many mobile web apps still use images for buttons. If you target the Android or iPhone web browser, CSS3 gradients are an extremely powerful resource, not only to make buttons. I spent a couple of hours playing with gradients and masks and here I present you a page stuffed with examples in all their text-only beauty.
Don’t you hate your own code 3 weeks later? I do. I finally tidied up iScroll code and managed to remove some insidious bugs. Please welcome version 3.2: smaller, faster, smarter.
The Slide-in menu exits alpha stage, gets Android compatibility and it’s finally ready for production.
Sometimes the screen of mobile devices is too small to fit all the controls, menus and options of your application. One solution is to create a slide in menu that the user can pull to access additional functions.
When I saw a retro radio on eBay the first thing I thought was to make a PC case mod out of it. It has been a nice jump into the past, when in the 90s I was enjoying building my own PCs.
The overflow:scroll for mobile webkit. Project started because webkit for iPhone does not provide a native way to scroll content inside a fixed size (width/height) div. So basically it was impossible to have a fixed header/footer and a scrolling central area. Until now.
I’m pleased that my original iScroll was useful to many. In the past months I received dozens emails asking for new features and bug fixes. I think it’s time to start developing a new version of the scrolling div for mobile webkit with added functionalities.
In my last post I was suggesting to stop cloning the default Apple UI for web applications and start creating custom controls. This time I want to put my words in practice and present you with a rotating wheel select control, 150 lines of code all included (HTML+CSS+JS).