Offset option about scroll-js

[markcellus]

No biggie, but my code at this spot is now more complex than it ought to be.

Haha, isn't everybody's? 😉

No problem. I understand. I'm always open to PRs for an offset but I'm usually hesitant about adding things like this to packages that will soon be moot--it just seems like unnecessary work imo. Especially if there are more suitable workarounds or features available that would eliminate the issue altogether.

I'm a contributor (mostly lurker) for current and upcoming ES features and W3C and WHATWG teams are introducing a lot of amazing things to the specification, many of which people don't even know are available. As a result, I've become a huge advocate for doing things using native JS if it can be done easily without reaching out for a library. We already have soooooo many bloated libraries in JS, it's ridiculous!

But thanks for explaining.

[markcellus]

Hi, just to clarify, what do you mean by "fixed header"?There are a number of ways a fixed header can be applied.

[julkue]

@mkay581 Thanks for replying. In fact I was meaning all ways:

• Fixed (position fixed)
• Sticky (only after scrolling)
• Fixed (position fixed) with dynamic height once you scroll down or up
• Sticky in the up direction (only visible when scrolling up) – e.g. like on Chrome Mobile

[julkue]

The first option would only require an option to specify an integer offset. All others would require a callback function

[markcellus]

I guess I'm still a little confused--sorry. So if you have an element on the page that is used by the first option, couldn't you just include the height of the fixed element, add that to the coordinate you want to scroll to, then pass that to the Scroll.to() method?

I'm unsure of why a callback is necessary for the other scenarios. The Scroll.to() method returns a promise that allows you to do things after the scroll is completed. Can you give me your exact use case?

[julkue]

Basically I'm talking about the .toElement() method since I don't want to calculate the position manually all the time I want to scroll to something. So the plugin handles the calculation and therefore needs an option to include an offset in that calculation. Doing a jump to the offset after the scroll is finished isn't really a solution as it wouldn't be smooth.

Let me give you a few examples of how other plugins added this option:

• https://github.com/callmecavs/jump.js#offset (offset)
• https://github.com/cferdinandi/smooth-scroll#global-settings (offset)
• https://github.com/hsnaydd/moveTo#options (tolerance)

[markcellus]

Ah, now I see.

I know that other packages have offset option, but I was more concerned with your use case to determine whether another approach may be better suited. AFAICT, adding an offset will only be necessary in a very specific corner case: when scrolling the viewport element (this wouldn't make sense for any other element) that contains a nested element that that sits at the top of the viewport (if scrolling down) or bottom of the viewport (if scrolling up), and the developer actually cares about being aware of the fixed nested element. That's a lot of specifics required to be in this scenario! So I'm hesitant about adding such a feature, but not totally opposed to it. :)

It seems more reasonable for the scrolled element to have padding set to the top of it to respect the height of its fixed content so that toElement() can be used without any calculation needed.

Also, can you speak to my question about the callback? Why do you feel this is necessary?

[btemperli]

I would use the offset-option too!
For the moment I am using the .to() method with all the calculations by myself but the .toElement(element, {offset: x}) (or whatever it will be) would be really nice.

[markcellus]

To clarify, my desire with this package is not to include features just because other packages have it, or because a few people ask for it when an alternative approach would be ideal, or to accommodate less-than-ideal approaches. I think requesting this feature only to solve the fixed item issue is not a good reason alone to implement offset. Especially when the issue can be solved by adding padding to the viewport as I mentioned in my earlier response.

The way to solve fixed item issue is:

1. add padding to the top of the viewport to accommodate the fixed item so that the offset needed is automatic
2. make the fixed item un-fixed, make an element exclusively for your scrolled content that is a sibling of the item, or
3. add padding to the top of the elements you want to scroll to

I would recommend that you do it one of these ways to eliminate the offset issue not only because it will fix any toElement() issues, but also other things too, like anchoring links on the page, using back button on mobile, etc

There are plenty of articles online that recommend that whenever dealing with fixed items when anchoring (or scrolling) in a page, the recommended solution is to add padding, like the top answers in this article or this one or this one. A css solution is much better than doing it in javascript, plus it's better for performance.

[julkue]

@mkay581 Let me clarify, I won't use this plugin as others are offering the options I need. So I guess at the end this is all that matters.

[markcellus]

No problem @julmot. Feel free to use any package you want. But don't expect for people to add features to an open-source package by opening an issue and not being willing to discuss it. You still haven't answered any of my questions or addressed any of my feedback, so not sure what type of response you were expecting without doing so. I will leave this discussion open for anybody else who may have more compelling reasons and/or use cases.

[julkue]

@mkay581 I'm out. I've replied to your messages, so I guess it's kinda fair to say that I was trying to help you seeing the point.

Anyway, good look with this project.

[markcellus]

You haven't addressed the alternatives. You haven't given me a use-case that can't be solved by any of the alternatives I mentioned. You haven't answered my question about your original request for a callback option.

There are a number of things to consider when using an offset. You will run into issues when navigating back to the element on your page using the back button on mobile devices. Also, if there are multiple elements you want to scroll to all with different fixed items within them, you are going to have to calculate the offset each time you scroll each of the elements. Why do all this in JS when it's easier and faster to be done in CSS (no calculation needed)? Sorry, there are just a lot of reasons that I think you should consider before using an offset option, but I understand your position. Thanks for your contribution.

[khtdr]

If I may, I too would find an offset very useful at the moment.

But there might be a very simple workaround. toElement does two things, 1. finds the elementScrollYPos and then 2. calls scroll.to on that position.

If those were decoupled, and both exported as helper functions (or methods, whatever), I think this issue would go away.

[markcellus]

Thanks for contributing @khtdr.

Finding elementScrollYPos can already be done by querying HTMLElement.offsetTop on the element you want to scroll to--that's really all that the toElement() method is doing. The only exception is for older non-evergreen browsers, you will have to add window.pageYOffset to the value when the scrolled element is document.body (which is also being done in the toElement() method).

Regarding your second point: scroll.to is already exposed, is that what you meant?

I'm honestly curious though, what is your use-case that makes you feel offset is necessary?

It should also be noted that this entire toElement method will soon be replace with scrollIntoView().

[khtdr]

I'm aware of the workarounds, I did one myself :)

I don't want to belabor this too much, because what you've given is more than enough to solve my problems. But since you ask, IMO code reads better with an offset. It represents the intention of the developer that wrote it: Scroll to this element, but not quite... adjust by this much.

Whereas if, the developer does this manually, you kinda of lose the flow of the code. Suddenly you are doing math, and maybe browser checks, etc. No biggie, but my code at this spot is now more complex than it ought to be.

But again, there are work arounds, just as you've shown. It's just natural to want your code to reflect the your thinking, such as in this case maybe.

Thanks for your efforts

[markcellus]

Closing this, as this is not an issue with this package but a request for a solution to what I consider an architectural issue with the projects herein. I am open to reviewing any pull requests for this feature but I would still strongly suggest that project teams do not look to this package to solve offset issues, but instead try to implement better alternatives similar to the ones I've already outlined in this thread, which will eliminate the offset issue entirely.