You can clone with
HTTPS or Subversion.
There are a number of reasons that including easing physics in a scroll polyfill is probably more than we need to do here:
1) Devices/browsers that do not support CSS overflow are becoming less common.
2) If a browser supports CSS overflow natively, but without physics, I'd be inclined to consider that fine enough, rather than trying to add physics
3) Even the best easing implementation feels awkward compared to native support, and it's noticeable to users. At best, it could feel natural in only one particular platform and awkward in others
4) The bulk of this script deals with easing and physics. Eliminating this code would make it lighter and faster
5) The primary problem with lack of overflow support is that content becomes inaccessible. The polyfill should fix that accessibility issue, while physics are more of a nice-to-have feature.
For these reasons, I'd like to explore a non-eased version of Overthrow. Simply making a CSS overflow container accessible should be a suitable goal for this polyfill. Easing could perhaps be an extension, but the reasons above make it less and less attractive to me.
I'd vote to skinny this down so it's just a basic scroller but it would be nice to be able to plug in a 3rd party scroller selectively. For example, most people would probably want to use overthrow but conditionally load & apply iScroll just for iOS 4 (is 3 supported too?) and maybe Android 2.2-2.3 for a slick experience. I'd rather have us do less but allow people to plu in other scripts in a narrow band way to target a handful of platforms. This could be more of a demo of how it could be done, not an integral part of this.
I agree that the greatest value of this workflow is in qualifying where this polyfill does and doesn't apply, and providing an accessible experience for both. That sort of safety net would be ideal for other more advanced scrollers to adopt as well, especially since the targeting is very difficult for end developers to get right (and unsupported devices can be left with accessibility issues). Unfortunately, the support of each script is different, so we'll have to see how realistically we can qualify their application in demo pages.
Either way, a simple scroll polyfill will be a good base for Overthrow, and perhaps most people who use it, I think.
I'd vote for adding some sort of scrollbar to Overthrow or provide some easy means of integrating them. I liked this in the JQM scrollview, where you could not really spot the difference between native scrollbar and scrollview scrollbar.
Without scrollbars scrolling just feels unnatural.
Also, I'm testing Overthrow performance in JQM listviews right now and it currently seems just awful. I'm having some pages where I need to basically claw and pull down the scrollable listview area with five fingers just to get it moving a few px (no need for easing in this case... ).
Here is a (work-in-progress)sample page. Try scrolling the right and especially left panel. The left panel (on iOS3) is pretty much impossible to scroll. I'm not really sure if this is Overthrow or listview related. What you can notice is that list items become highlighted as you swipe across them which seems to be the problem, because you can scroll the "list-free" right hand panel much better (not perfect) without stalling. However only in one direction. Try scrolling down all the way and then back up and the scrolling stalls again, too.
Should I file a separate issue for this along with a panel-free sample page? Here or in JQM?
We were looking for a way to selectively add iScroll, and Overthrow seemed like a good replacement. But @scottjehl does make a good point about providing with a polyfill mode. I don't necessarily agree that all the physics stuff should be tossed, as it can potentially eliminate the need for iScroll, and a lack of physics may make iOS 4.x devices seem very very wrong indeed when scrolling, but it might be good to have the option.
This is now in Master.