I love jQuery, I use it everyday, you can spot it even on this blog. It’s a life saver in the times of desktop browser discrepancies (yes, I’m talking to you IE), but modern browsers and specifically mobile browsers are good enough not to need any bloated framework on their shoulders. In this post I’m showing you that 90% of the times you are using a framework for nothing.
I finally took the time to fix some nasty bugs that were infesting iScroll. This has been the most important bugs hunting session since v3.0. Hurry up, take it while is hot.
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.