Native style momentum scrolling to arrive in iOS5 | Hacker News Reader

Native style momentum scrolling to arrive in iOS5

johanbrook.com

79 pointsjohanbrook29 comments

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.

OnSwipe is the new scribd

It's death? This particular news only means that it would get better.

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.

its not ios specific, this is a commmon problem on all touch devices, I am actually very curious as to when this is going to hit android.

How does native Android scrolling improve over WebKit scrolling currently?

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.

At least on iOS, you could scroll one of these elements using two fingers but it was awkward and felt strange.

You can do this on Windows Phone 7 too (and I believe Android), but it's still very awkward.

Last time I tried it (default browser on Nexus One with 2.3) I couldn't; this meant I couldn't read about Android on Google's site about 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?

But I guess that’s really not such a big problem.

There are lots of context specific css attributes, what does overflow:scroll mean when printing a page.

as for the actual names, yeh I imagine there was already a lot of bikeshedding involved and could go on for years, I am just glad the code is there.

what does overflow:scroll mean when printing a page.

Something different than overflow: visible, I'd imagine. Maybe cursor: pointer would be a better example.

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.

> window.onerror is now supported.

I find this even more exciting.

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.

Any idea if this will be ported into the typically gimped UIWebView?

That's an excellent question. I'll try to find out.

how useful is this feature, given the share of ios users still on 4.x? i imagine we have a ways to go before anyone feels comfortable using it freely?

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.

Not to mention iCloud, hugely improved notifications, iMessage, etc. I don't think Apple will have any problem convincing people to upgrade.

presumably this feature will be useful when ios5 ships and the majority of iphone/ipad/ipod touch users install it.

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."

Well, it's barely conceivable that Apple would take it out before the final but it's not very likely.

Glad to see that this will not be a part of a patent dispute that hurts everyone, but something that all Webkit-based browsers may benefit from.

Reply on news.ycombinator.com