js-is-stuck does not seem to be added when sticky is supported

[ishields]

I'm using the latest version of chrome which supports position: sticky. Unfortunately I'm noticing that js-is-stuck does not seem to be added. Is this a known issue?

I'm defining my sticky element with jquery

$('#element').stickybits({useStickyClasses: true});

The element is sticking correctly but the isStuck just does not work.

[ishields]

Digging in, I think the issue has something to do with "stickyBitStart". Essentially that is smaller then it should be and as a result the js-is-sticky class gets added before the element is actually sticky.

[yowainwright]

Dang—no fun!!!

@ishields, could you share some info so we can figure this out?

1. I made codepens for us to hack on in vanilla JS and 1 for jQuery.

2. Here's a gif showing that it appears to be working for me (not saying that it IS working for everyone 😬).
   

I'm here to help so let me know what I'm missing. ~Thanks again!

[ishields]

Interesting. So I haven't replicated it yet in code pen because it requires a more advanced use case I think. Basically it seems like the calculation of stickyBitStart changes depending on your scroll position on the page. I put a console.log underneath the line

var stickyBitStart = this.el.getBoundingClientRect().top;

Then I refreshed the browser a couple of time with different scroll positions. Depending on my scroll position when I refresh, this value changes significantly. It is only correct when I'm scrolled to the very top of the page. Because this value is wrong, the classes are added at the wrong times (before or after the element becomes sticky)

I fixed this by using the jquery method offset().top "offset().top". This strategy produces a consistent number thats not based on where you are scrolled on the page. You also need to take into account the offset thats passed in. So this line became

var stickyBitStart = $(this.el).offset().top - (offset || 0)  

And the last problem seems to be when developing responsive sites. If you change the width of the browser, the start and stop positions of these elements need to change too. As a result I think the calculations of stickyBitStart and stickyBitStop need to be dynamic. So in other words there will likely need to be a method to generate these numbers on the fly rather than set them as constant variables.

Thoughts?

[yowainwright]

My initial thought is:

• Can you make a codepen to show the issue?
• Once I can see the issue too, can we make a codepen together and fix the issue? 😊

If you can make a codepen showing the issue, then I will work with you to make it work how we want.

I think/hope with the stickbits .cleanup method, we can get your issue working perfectly. 👌

[yowainwright]

@ishields, thanks for you notes. I'm going to cancel this issue.

Reach out if you have anymore notes/questions/ideas. 🙏

[wernerkrauss]

Hi @yowainwright, it still doesn't apply the js-is-stuck class in Firefox. I installed stickybits 1.3.5

[yowainwright]

@wernerkrauss 😔 Do you have link you can share? ...Or is the issue visible in demos? 🙏

[yowainwright]

@wernerkrauss I'm not seeing that issue here...?
https://codepen.io/yowainwright/pen/36449183ca18af18f3005734b0251769/

[DanielRuf]

Still, both classes are not applied here on our side.

[DanielRuf]

It seems we have to define scrollEl as many elements do not bubble up the scrolle event to the window object by default.