Use another wrapper than window/document

[myconcretelab]

I'm working with this GREAT plugin. I'm really love it (some are WIP): http://codepen.io/myconcretelab/pen/wkduG http://codepen.io/myconcretelab/pen/ctuoa http://codepen.io/myconcretelab/pen/aHkih

I'm asking if is it possible to easily pass another wrapper into the constructor. it seems that if elements are in a div, somewhere in the page i will nee to set all these properties : scrollMonitor.viewportTop, scrollMonitor.viewportBottom, scrollMonitor.viewportHeight and scrollMonitor.documentHeight ? Is it possible to add this feature ?

[stutrek]

11 is a pull request that does just that. I haven't accepted it because I wanted it to determine the scroll container automatically and avoid additional dependency on jQuery.

[myconcretelab]

Thank you for answer. Is'nt possible to keep jQuery out and change the container as a option, like top or bottom :

 scrollMonitor.create( element, {top: 200, bottom: 50, container:element})

?

[stutrek]

This solution appears to be straightforward, but it brings ambiguity to the API. Should it measure the actual viewport or the container? What happens if the element is scrolled into the container, but the container is not in the viewport? What if the element is 100% in the container, but only 50% in the viewport? Should two separate sets of events cover these situations?

I don't want to support this until it is done correctly, which may come soon(ish) since summer is over. I recommend using @hswolff's fork until then. I would appreciate your input on what you think is "right" for these situations. If I knew it would have implemented it.

[stutrek]

Also, great work on the works in progress, @myconcretelab.

[myconcretelab]

Hi, thanks for answer. But i don't understand why you want to mix viewport AND container. In my mind, when we add a container in option it replace the viewport. So the "only" thing to calculate is if the element is in the container, not viewport.

<div class="container">
  <div class="element"> ... </div>
</div>

<script>
scrollMonitor.create( ".element", {top: 200, bottom: 50, container:".container"});
</script>

[anthonybruno]

Any updates on this? Would love the ability to specify a container that didn't rely on jQuery.

[igregson]

+1 for this, please :)

[kevinkl3]

This feature would be great!

[OverZealous]

Is there something that can be done to help with this? I started using this (via an Angular module), which will have a massive effect on our application.

But I can only use it on scrolling elements—our SPA doesn't use window scrolling at all.

[OverZealous]

Actually, this looks like it won't work for me even with that change, because it looks like it won't work well with items that dynamically change size (because you'd have to manually update the watcher). Great library, though!

[hoangnguyencong]

+1 for this. Pls :)

[ryannichols]

Agree with the previous in regards to being able to specify an element as opposed to the viewport. The container is what's important, that container can be any element - the default of which would be the viewport. Doesn't seem ambiguous at all to me.

If someone needs to know that the container itself is on or off the screen, then they should add a second watcher to the container. It should be up to the developer to track those states and write logic for what should happen in each case.

[stutrek]

Here's the API I think is best. LMK if anyone interested in implementing it in a PR and I can help with a more specific spec with errors, etc.

// create an instance that watches scrolling of a specific element
var containerMonitor = scrollMonitor.createContainer(containerElement);

// create watchers that watch the scrolling of that element
var watcher = containerMonitor.create(childElement);
var watcher2 = containerMonitor.create(otherChildElement);

This is the smallest change that could be made to the API, it might even be a minor version since scrollMonitor.create() would just reference an instance that watches the window. The watcher creation API is the same if you're creating from the window or a different container. It also makes it simple to clean up after yourself, a .destroy method would remove all listeners from the DOM.

There is a wide consensus that it should only notify you when an element scrolls into its parent, and that the visibility of that parent is irrelevant.

[stutrek]

EVERYONE! It's been almost a year, but we have substantial progress!!

Leave your comments and concerns on stutrek/scrollMonitor#53

[stutrek]

Implemented in version 1.2.0, check the readme for docs.