Here's a grab-bag of scrolling-related things I'd like to work on in a Scrolling Module, in no particular order:
When writing a chatroom, the standard display idiom is to have new items appear at the bottom. Once you have enough content to scroll, you typically want the scrollbar to "stick" to the bottom, rather than the top, so that when you add a new message, it'll be immediately displayed without the user having to manually scroll down.
However, when the user isn't already at the bottom (if they've scrolled up to read something earlier in the conversation), you don't want to change their scroll position. You want it to be "sticky" when they're close to the bottom edge, but not otherwise.
This can be done with JS, but it's much trickier than you would think to get completely right. The Google Chat widget, for example, has this behavior, and they still have behavior bugs sometimes where they don't scroll correctly. We can do this very easily and correctly in the browsers, and just expose a simple control to the page author.
Here's a mailing list thread about it.
Vaguely related to the previous item, when you're scrolled halfway through a list, like your Twitter timeline, and something new gets added to the top, you'd like it to not disturb your current reading. Instead, it pushes the content you're reading down, so you have to stop and scroll down with it. The same applies to removing or just resizing an element - right now, if the action happens above your current reading position, the stuff you're looking at will shift around. (Twitter used to have this problem, but have fixed it - they use JS to adjust your scroll position manually when they add new things.)
It would be nice to be able to declare that you're probably going to be live-inserting elements into a list, so the browser should hold the display stable for the user when the thing being inserted is off-screen.
Here's a mailing list thread about it.
When you're scrolling in a list of distinct items, it would be nice if the browser preferred to stop scrolling on "boundaries" between items, so you didn't have either a little bit of the previous item poking out from the top or bottom, or a sliver of the first/last item off-screen.
Native apps do this in a few different ways:
- spreadsheets tend to only scroll in "jumps" between notches, so it's literally impossible to scroll halfway between a cell (at least, on the top/left edge of the sheet)
- some apps will adjust your scrolling momentum if you would land near a notch, so that you'll instead land exactly on it, but don't otherwise mess with your scrolling
- some apps let you scroll arbitrarily, but will "drift" your scroll position back to a notch as soon as you let go, so that you always end up on a notch eventually
Obviously, in one of the "strict" notch regimes, you don't do anything if the item is larger than the scroll container (otherwise it would be impossible to look at parts of the item!).
Scroll Momentum and Bounce
People on mobile devices have had it good for too long. One quick finger gesture, and their screen is flying through a list. We here in mouse-land have to either spin our mousewheel for minutes to go the same distance, or target the scrollbar with our tiny mouse pointer and carefully drag it to where we want.
With touch screens gradually coming to laptops/desktops, we'll want the same kind of momentum-based scrolling. Heck, there's no real reason we couldn't add it to mouse-wheel based interaction, either - a quick roll could give some momentum and carry you further through the list, arrested by spinning it one click in the opposite direction.
I'm not sure whether we can just expose this as a toggle, or if authors would need control over the momentum function somehow.
Similarly, when you hit the bottom of a list during a high-momentum slide, some mobile OSes have a little "bounce" at the end. Some do it with a literal bounce off the bottom, some "overshoot" the end a bit and bounce back (iOS), others just have a visual indicator that you've hit the bottom (Android's quick orange/blue flash on the screen edge that hit the end). We probably want to expose this somehow.
Microsoft has a bunch of scroll-related properties they added to Windows 8 that would be good to cull for inclusion in the web platform proper. I'll insert a link when I find it again.