Closed saiwong closed 11 years ago
Works, but I think some improvements could be made.
listView.parent
existing only under certain conditions, listView.$scrollParent
could exist always. If it should scroll within a containing element, $scrollParent
is set to that element; otherwise it's set to $window
. Then all scrolling-related references to $window
could be replaced with $scrollParent
, and the code would trivially work for both.overflow-y
property of each containing element. If they're all visible
, the ListView should use $window
for scrolling; if one is auto
or scroll
it should use that containing element. If it's hidden
, god knows what you do -- seems silly to use Infinity at all in that case, but I guess just use the containing element to save CPU cycles. inherit
would be a slightly more annoying case, but you just check the parent's overflow-y
and use that for the current element.Thoughts?
I think the $scrollParent
suggestion is good and I can add that in.
For auto-detecting what to use, I think that only opens it up for issues with fringe cases that we can probably never fully enumerate. It makes sense to for the integration code to explicitly specify it so that there is no assumptions made. Less magic = better!
Fair enough. I may still give auto-detection a shot in the future, but a configuration option that forces it to be one way or another is still a useful thing even in a world where auto-detection works. Add in the $scrollParent
and I'll merge it in!
Added $scrollParent
to commit!
Excellent! Merging in.
You are right. You should submit a fix for this.
Added support for infinite scrolling for elements with overflow set to auto. This is enabled via the
options
hash by settinguseElementScroll
totrue
14