dollarshaveclub / stickybits Goto Github PK

If the size of the sticky element is not very large it is possible to scroll fast enough that the stuckClass is not removed.

If you have something above the parent containing the bottom sticky, it doesn't move the bottom sticky into place until the top of the page passes the top of the parent element, and then it jumps into place at the bottom.

Tested on Firefox with bottom sticky settings:
{useStickyClasses: true, stickyBitStickyOffset: 0, verticalPosition: "bottom", customVerticalPosition: true}

Expected behaviour:
Bottom sticky snaps to bottom of view as soon as possible (i.e. snaps midway into parent element on page load).

Is there any way to disable/enable the plugin under/over a certain breakpoint? I only need my columns to be sticky when they're sitting side by side and not collapsed on top of each other.

Right now I'm using a couple of !important to override the plugin inline styles but ideally it shouldn't add them when I don't need it to do nothing.

Is there any way to stop and clean up an instance of stickybits? If not, it would be nice to add one. For example, if you want to use the stickybits within a React component, it would be good to be able to remove it (especially the event listener added by manageStickiness()) when the component is unmounted.

@pwfisher @briangonzalez @jakiestfu 🙏🙏

From what I can tell, the js-is-sticky class is added when the element gains the ability to stick, and the js-is-stuck class is added when the element sticks to the bottom of its parent. But how do we tell when the element has gotten stuck to the top of the viewport? I thought the js-is-sticky class indicated the element was stuck to the top of the viewport. But it only indicates the element's position is set to sticky.

I made this Codepen to demonstrate: https://codepen.io/matthewmcvickar/pen/VzbqLN

The green toolbar in that example gets the js-is-sticky class after the viewport has been scrolled a few pixels, but I don't want it to get that class until it starts sticking to the top of the viewport. Is this possible?

[NOTE: This is a bug! I was right in my initial interpretation of what js-is-sticky means.]

[TL/DR: This happened because my sticky element wasn't the first child of its parent. Until this bug is fixed, I rearranged the HTML to wrap it differently as a workaround, and now this works.]

Thanks for the great plugin!

We are using css modules, which basically manages class names to avoid name conflicts. Therefore, it would be useful to be able to define the class names by yourself.

As far as I can see from the source, this is not currently possible?

As an example:

import styles from './styles.module.css';
// ...
stickybits(element, { useStickyClasses: true, classNames: { isStuck: styles.isStuck } });

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.

For some reason I had to use

z-index: 10; /* in front */

a lot for the elements I set sticky, even though nothing else on the page had a z-index, otherwise they scrolled behind whatever other things were in the same container. I didn't notice because my element was really skinny, so for a while I just thought they were just stuck in place and nothing was working, heh.

The behavior is different when using native position: fixed where I didn't have to set the z-index.

Doesn't it make more sense to use a passive scroll listener as preventDefault() is not used?

Steps to reproduce

1. Apply stickybits to an existing element without providing a scrollEl option.
2. Open on IE10 in Windows 7.

What should happen

Sticky bits galore!

What actually happens

In IE10 on Windows 7, I'm getting the following error:

Object doesn't support property or method `getBoundingClientRect`

From looking at the minification it becomes clear that this error is coming from stickybits.js, line 74. Since I have initialised without option scrollEl, se should be window.

I don't see any documentation saying that window should support getBoundingClientRect(), so perhaps se should default to document.documentElement?

I've never seen a scroll event that uses Request Animation Frame in the event function. Is there somebody that can help me understand the reason why that's the approach for this project? Would it not be better to use only RAF?

None of provided codepen examples works in Google Chrome 55 on Ubuntu Linux. In Firefox all works as expected.
Error in Chrome devtools console:
se.getBoundingClientRect is not a function at Stickybit.manageStickiness

None of the Codepen examples work on iPhone mobile safari.

I tested the following on iPhone 6S, iPhone 7 - iOS version 10.3.3:

https://css-tricks.com/stickybits-alternative-position-sticky-polyfills/
https://codepen.io/yowainwright/pen/QdedaO
https://codepen.io/yowainwright/pen/VPogaX

I think it would be a good idea to add a boolean property to the stickyBits instance, which indicates if the plugin is using the native implementation of position: sticky.

This would allow users to simply check via JavaScript if the position: fixed "polyfill" is active or not, to for example apply additional styles dynamically.

I'm thinking of a property called isNative or isUsingNative. Also a property which indicates that the instance is using position: fixed would work (like for example: isPolyfilled).

Hi!

I'm evaluating StickyBits for use in the (React) app I'm developing, and it's important to me that the library exits (i.e. doesn't attach an event listener) if the browser supports position: sticky.

I tried looking at the source code and couldn't find any check for the browser support.

Please let me know if this isn't the right place to post this.

I'm using this library in part due to the sticky class toggling (as well as for the polyfill). Although I've ran into some issues for when the class is added or removed.

If the scroll position is not at 0 on pageload, the sticky classes don't get added properly. for instance, if the page loads on an anchor (id hash), the script thinks that's where the page head is. ( you scroll up and the stickyclass is added, but you scroll down to that anchor point, and the stickyclass is removed).
Likewise, if you scroll down a little ways, and reload (without a url hash), the stickyclass is always present, and never removed.

Here's my bin, blue header background is not sticky, purple background is sticky.
http://jsbin.com/rejuramuku/1/edit?html,css,console,output

You will have to view the bin without the editor in order to refresh with an anchor hash url. http://jsbin.com/rejuramuku/

Hey,
Just wondering when you'll release 1.3 to npm? Thanks!

For example, rem or em, would be really handy.

All my css sizing is done in rem so matching the sticky bit offset with the header size so it all collapses nicely is bit of a hacky guess at the moment.

When refreshing a scrolled website, the browser automatically tries to keep your position. This causes stickybits not to apply its classes even if the option is set to true. I think classes should be there just as inline-styles are.

Here's a dev link where you can check this issue (http://dev.llos.co/cupofcouple/jessica-barensfeld-simon-howell/). If you want to see how the element gets stuck at the bottom you'll need to expand the comments section (just tap on the "Comments (N)" link to do that.

Version 2.4.0 of eslint-plugin-import just got published.

This version is covered by your current version range and after updating it in your project the build failed.

As eslint-plugin-import is “only” a devDependency of this project it might not break production or downstream projects, but “only” your build or test tools – preventing new deploys or publishes.

I recommend you give this issue a high priority. I’m sure you can resolve this 💪

Your Greenkeeper Bot 🌴

It would be nice if the library would contain typings for Typescript, which would offer users to use this library in a Typescript project instead of doing import * as stickybits from 'stickybits'.

Also it would be nice to export the Stickybit class, to use it only for a single element without creating a Multibits instance.

I've realized that the way I use this library, it's basically only for the styling provided by the "sticky" and "stuck" classes. It's much easier to polyfill my app in css than relying on the classes added by the js because the css is more extensible.

The js is fighting against my stylesheets by overriding properties on the element in an attempt to implement the 'polyfill' but I don't really need it at all. I banged my css with !important everywhere to get rid of it, but a disablePolyfill on the options would be nice (it could be ligher on the client if it skips the polyfill part).

Also, ability to set the name of the classes js-is-sticky and such should be ony a 1-liner as it's already set using a const.

Firefox 54.0.1 (32-bit)
Chrome Version 59.0.3071.115 (Official Build) (64-bit)

{useStickyClasses: true, stickyBitStickyOffset: 0, verticalPosition: "bottom", customVerticalPosition: true}

Works on Firefox, but on Chrome it does nothing. It adds position: sticky; but no position: bottom, so the element doesn't stick to anything.

I've heard that pushing 0 to css without a px causes issues on Chrome, might be a similar issue here.

I've an element on the top of mobile page and it sticks on top as expected 👍 after using
stickybits('#title')
I'd love to have ability to go back to normal state when somebody scrolls to the top - is it possible to achieve this someway ?

I've copied a fairly simple Codepen demo I found and have embellished it slightly.
Link to my pen: https://codepen.io/IanYates/pen/ZyaQXZ

In latest Chrome (Version 61.0.3135.5 (Official Build) dev (64-bit)) on Windows you can scroll down and get image 1's header behaving properly, and image 2's header behaving properly but image 3's header doesn't stick.

In IE 11 this seems to work properly.

The CodePen I originally sourced from (https://codepen.io/yowainwright/pres/QdedaO) had a slightly older JS version that didn't work in IE 11. I've updated its JS code to the latest from the dist folder here. Apart from that change, and adding some more divs and the img elements, everything is the same.

I've tried multiple stickybits calls (targeting a specific div each time) and using a single stickybits call (selector targets all child divs). No difference.

With only 2 images it seems to behave correctly.

Any thoughts?

Thanks for the library - it came up in my Google news feed and happens to be exactly what I've been looking for :)

This plugin doesn't work on IE11 because window.scrollY is not supported.

Hello,

I'm looking to use stickybits for the project that I'm on. However, branched off of your example and replaced the html/css with my own layout. When I loaded this example on Edge and IE I am not seeing sticky behavior. It works on all other browsers I've tried so far.

Here's the code pen that I've been working with https://codepen.io/bxyoung89/pen/BZeyaE

My intention is to have the yellow section be sticky (as it is in chrome) but it doesn't seem to be moving as it should.

Hi,

I need to make some changes to other elements on the page outside of the stickybits parent element when the selected element becomes sticky. If the stickybits classes were also applied to the body I could hook my CSS transitions off that. An alternative is an option for a callback function perhaps.

Any ideas the best way I can achieve this?

Am I correct in understanding that in IE, as css sticky is not supported, this will add a position:fixed? I ask because I am dealing with a div inside a flexbox item. If I position fixed it, it looses it's parents width and no longer behaves as if it is contained in the parent. Thank you (sorry, not sure how to add the "question" label.)

Hi
When position: fixed is applied to the sticky element (in IE) it doesn't preserve it's width see bellow:

Thanks!

Firefox 54.0.1 (32-bit)
Chrome Version 59.0.3071.115 (Official Build) (64-bit)

Using {useStickyClasses: true, stickyBitStickyOffset: 0}.

Here's a codepen that demonstrates the issue: https://codepen.io/maxlapides/pen/QMgQxZ

You'll notice as you scroll down that both Element 1 and Element 2 receive the js-is-sticky class even when only Element 1 is sticky.