Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: