Sticky component accuracy improvements

[achord]

The sticky component does not accurately stick to the top, especially when scrolling fast. I've solved this issue before by getting the height of the sticky-element with javascript then offsetting when stuck. This method needs a placeholder element to adjust for the difference. Here is a working example. I'd like to participate in the conversation around possible solutions.

There is also an issue with the width be set by JS on resize.

• [ ] Accuracy of sticky component
• [ ] Width issue on resize

[RyanMillerMath]

I'm a bit confused. Could you explain to me what you mean by offsetting by the height of the sticky element when stuck? Also, in this example, what does the placeholder actually do? I deleted it in dev tools, and it didn't seem to change anything.

As for the width issue, the real issue is that the component relies on position: fixed, which breaks the element out of the document flow. My solution to that was to just make the width of the content explicitly the width of the container minus its borders. It's admittedly a bit hacky, but I poked at it for a couple days and couldn't really find a viable solution otherwise. This happens in a scroll event. I could just extract that logic out and make it happen on resize as well. I'm super open to anything better if anyone knows any tricks to deal with persistent fixed positioning behavior.

Thanks for the input!

[achord]

@RyanMillerMath The example I provided is quite old, so forgive any jankiness. You are correct, the fixed element removes it from the document flow. We could get the correct width with JS, or explore our css options.

[achord]

@RyanMillerMath This is my first week, so I would like some guidance on how the team would normally go about an fixing an issue like this. For example, I could put together a codepen illustrating my thinking.

[achord]

There are a couple of common challenges with sticky elements that you are probably aware of.

1. Removing the element from flow makes its width not relative to its parent. We can fix this with JS, but we must also account for resize.

2. When setting an item's position to fixed, we get a "page-jump" because the container is now missing content. We can either add a placeholder element to take on the missing height, or set the containers padding to compensate.

I've put together a very rough code pen demonstrating the solutions above ... but wouldn't it be nice if could use position:sticky ? What are some thought on doing this with JS vs. position:sticky with a polyfill?

[RyanMillerMath]

I'm just a friendly neighborhood coder, not an actual Reveler, so I can't really help you there unfortunately.

If I'm not mistaken, sticky components are around to make a better supported version of position:sticky behavior because it's not supported in IE.

I get what the placeholder is there for now. I was totally overlooking that once it pops into position: fixed, it breaks out of the container when it breaks out of the document flow. Solid catch, @achord!

I'll patch it up this weekend.

[RyanMillerMath]

So, I've actually come back and completely reworked the Sticky component from the ground up to be way more usable because my initial interpretation of what the component was supposed to be was way off.

Before I submit the PR, I'd like clarification, if you could when you get a chance @achord, on why a stuck element needs to track its container's left positioning in the width setting function, i.e. the following lines in setWidth() from your codepen:

currentX = stickyContainer.offsetLeft; e.style.left = ${currentX}px;

Is it because the implementation in this codepen has left: 0 for the sticky class? If so, would giving .sticky left: auto & right: auto be a viable alternative?

[thomasknoll]

Hey @RyanMillerMath sidenote, I tried to drop you an email at the email on your website, but google kicked it back to me because the address couldn't be found, or is unable to receive mail. Willing to drop me a note to hello @ revelry.co ?

[achord]

@RyanMillerMath Good catch. I've updated the CodePen and removed the left css attribute and the currentX var. I've tested this in Chrome, FF, and Edge.

[jwietelmann]

Is this fixed?

[RyanMillerMath]

For the accuracy issue, @achord was making a mild adjustment to account for the sticky div's height resizing a couple months back if I'm not mistaken, since only width is being resized currently. If that got merged, as far as I can tell, the scrolling jank is situated for the proposed accuracy issue.

Since the resizing issue here was in reference to the sticky resizing on window resize in general, the resize issue mentioned here possibly evolved into a new issue regarding div resizing discussed in #226. I'll continue the discussion for that issue in #226. So, I think this is safe to close provided that @achord's height fix was merged.

[revelry-stalebot[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.