I'm hoping this will be the death of that hideous OnSwipe Wordpress theme which tries to make a perfectly functional smooth-scrolling website and turn it into a faux iPad app with jerky, glitchy scrolling and none of the usual site navigation. On top of that, the "View as standard site" link doesn't work 90% of the time.
Oh, that theme is so awful. Besides the horrible scrolling it is also very buggy for me, especially after rotating the device. Who had that idea?
Browsing websites on the iPad works great. There is no need whatsoever to turn a standard website (like a Wordpress blog) into a web app. That’s just stupid. This should be used for web apps, not for websites.
Agreed. Every time I land on an OnSwipe-themed page, I immediately hit my Readability bookmarklet. Sometimes I don't bother and just hit the back button.
I often get frustrated with web pages that are modified/altered to work with the iPad. OnSwipe annoys me the most. I also find it frustrating when a mobile content width is defined which takes away my ability to zoom.
Oh, finally. One of my projects recently (which I have yet to complete) has been a scroller that, unlike any other I've seen including Apple's own, correctly imitates iOS' native behavior. But I wouldn't envy myself having to make it run smoothly, and in any case it would be all wrong on other operating systems; this is a much better alternative.
It seems a bit inelegant to introduce a CSS property for this. Those vendor prefixes should be reserved for properties that either are in the process of becoming a standard or that the vendor wants to become a standard. I don’t know how that property fits in there, it doesn’t seem like something that should be part of the standard, it seems very iOS specific. That’s not what those vendor prefixes are there for.
What meaning would that property have on other platforms?
By the way, there’s even more good news for web apps. contentEditable is supported in iOS 5, in fact Apple devoted a good chunk of a WWDC talk to contentEditable.
it doesnt, but currently users cant scroll elements that have hidden data with overflow:scroll on either devices, this fixed it for ios, I would like to see the same fix for android.
Hm, ok. I guess the syntax rubs me the wrong way. Why does “overflow-scrolling: touch;” mean “use native scrolling”? What are the other values? What does “overflow-scrolling: touch;” mean on the desktop?
Usually you scroll the page when you touch the screen. In this case you scroll the overflowed element first when you touch. Traditionally embedded elements required two finger scrolling which was a usability kludge. You'll have to specify it somewhere and I think CSS is appropriate for this.
Scrolling with bounce is nice, but does this mean you can finally use position fixed and have it fix to the actual phone window? That's always been the real issue: you couldn't fix a toolbar to the top of the window, for example.
Position: fixed is also coming in iOS5, but it's not a perfect implementation yet. For instance, zooming does weird things to fixed elements if it's enabled, and it still covers the scrollable page area.
For my own purposes, native div scrolling is a godsend. The JS hacks were okay, but they still weren't as smooth, and worse, I had to do a lot more event juggling to handle both scrolling and the other touch controls within divs.
Well, I think the number of users on 5.0 will go up a lot when 5.0 is actually released...
But really, 5.0 has a huge upgrade-incentive, and I think it will be pretty safe to assume people who know how to save a webapp to their homescreen will update.
And, of course, there's fine print, down at the bottom of the post in very pale letters: "Note that this is in the second beta, and that it’s not dead certain that these features will arrive in the final version of the operating system."
