a) Clean up multi-axis support [ being able to scroll horizontally and vertically at the same time ]. It's currently supported, but doesn't hold up cleanly all the way through the API.
b) Clean up scrollbar implementation - right now the scrollbar is 3 separate elements. I remember looking into it and thinking we could do it with just 1 piece.
c) Just a general high level pass of the API.
d) Clean up the ScrollView-List plugin - it doesn't really solve the real problem it was mean to solve - laying out horizontal LIs. It's API could also use some cleanup.
a) Support Nested ScrollViews cleanly
b) Support Scrolling along with Page Panning
c) Enhance Pagination support, so that it doesn't need to depend on element boundaries
Users can feed in page boundaries programmatically, or it can default to the width of the scrollview
d) Allow support for lazy content more cleanly
Define scrollview content dimensions without content actually being in the DOM
e) Support ScrollView reuse more cleanly
e.g. if I have a Livestand type application, where I have N horizontal pages inside a horizontal scrollview, and each page has a vertical scrollview, allow user to easily do this with just 2 scrollviews - 1 horiz + 1 vert, instead of 1 horiz + N vert.
f) Provide a Data List Management Plugin
So it can also be a full blown carousel - addItem, removeItem etc. Consider leveraging ArrayList for this.
g) Provide a UI Plugin for prev/next/page N of M UI. Consider leveraging Paginator for this.
h) Currently SV will determine whether or not it should scrollview vertically/horizontally based on the relative dimensions of it's boundingBox and contentBox. There may be cases when the user wants to over-ride this. Support an axis attribute to allow this.
a) Rely on native overflow:scroll support and scrollbar in iOS5 (and other OSes/Browsers when available).
b) Remove timer based animation for Flick, and replace with pre-calculated end point (should just be able to do the math to get it) - which can then use CSS transitions instead - maybe with a keyframe calculation function. We've been meaning to do this since the day it was introduced.
a) Optimize H/W accelerated memory usage.
Instead of accelerating the whole scrollview, accelerate only the prev/current/next page. Free up GPU memory after transition.
b) Improve instantiation performance/kweight.
NodePlugin/WidgetLite?