New features in v1.0

[terwanerik]

New features in v1.0

[thasmo]

It would be nice to define a function for the offset option, so it's possible to calculate the offset dynamically.

[terwanerik]

Yeah its scoped so this in the callback is the HTMLElement. It takes one attribute, the Trigger object itself, containing settings, position, the element etc.

[terwanerik]

The current version of ScrollTrigger (0.3.x) has this as well, check out the callScope and showCallback

[Windvis]

Hey! These are the things I think that could be nice to have:

1. Add a direction option which trigger the class only from certain directions (for. ex, only if you scroll from top to bottom)

2. Add an option to trigger other elements based on the current position. For ex. If you refresh te page, trigger the elements that are above the current position. This of course would only make sense if directions are implemented (and in previous example only the elements with the top-down direction would be triggered).
   Another option would be to add new API methods which can make elements before or after a certain element / position visible or invisible.

3. Make it possible to configure the data- attribute namespace. I can imagine that data-scroll can conflict with other libraries (or custom code) since it is really generic, adding an option to change the namespace would solve that.

4. Make it possible to group similar elements. That way you don't have to repeat the data-attributes if you have multiple 'groups' of elements on the page with different options (so you can't set it in the default options). Custom attribute names could solve this as well, by giving each 'group' a different attribute. (This would require multiple ScrollTrigger instances though, is that a problem?)

5. When you create a new instance of ScrollTrigger it automatically adds the invisible class to the elements. I think it would be better to make this optional. Some projects don't need this class so in that case these are unnecessary DOM changes.

6. Add a callback which will be called right before ScrollTrigger adds / removes classes. This could then be used to check if the classes need to be added and influence ScrollTrigger by returning a boolean. Some of the previous points can be solved with this (if given the necessary parameters).

PS. I have limited experience with this library, so I'm sorry if some of this is already possible or if it's not useful at all.

[terwanerik]

Thanks for the input! The numbers 1, 3 and 6 will be implemented in v1.0. I'm going to handle 4 a little bit differently. The other points are not on the list for now, just because they take up a lot of time, and can be implemented in client side code.

I already started development (you can check it out in the v1.0 branch), by default the ScrollTrigger will init all html elements with the data-scroll attribute, you can then query all the triggers to change settings for a group of triggers. E.g. something like this:

const trigger = new ScrollTrigger()
const h1s = trigger.query('h1')

h1s.forEach((h1) => {
  h1.once = true
})

You can also add new triggers to the ScrollTrigger by using a query, and giving a set of options for that group of triggers.

[Jeremy-Knudsen]

Re: #6, would the callback pass back the triggered element so that it could allow me to call my own JavaScript functions? That way, upon an element being triggered (let's say it's a video), I could then call my own JavaScript function to play the video. I would like the element to be passed back in the callback so that I could read it's data-attributes as well. Also, it would be great if I can use the scroll position to manipulate the triggered element.

[Jeremy-Knudsen]

The main reason I checked out ScrollTrigger was because of its small payload, as opposed to ScrollMagic. However, ScrollMagic had those features.... I'll try out ScrollTrigger again. Thanks @terwanerik !