Styling for no/native/polyfilled position:sticky #33
Conversation
This gives dev (and their stylesheets) the possibility of modifying the look of the page depending on if the result has no sticky support, native support or polyfilled support.
If the purpose of `destroy()` is to remove the polyfill’s capabilities, it doesn’t need to remove the `sticky-native` class, which could still be relied on by the stylesheet.
Some browsers need the sticky element to have a `top:X` or `bottom:X`, this now determines if `polyfill-active` is added to the document or not.
|
eek - just spotted a regression bug - line 145 rolls back commit c58fbea (nOOb mistake). Apologies. |
allowing the sticky behaviour to activate at an offset other than the container hitting the top of viewport. Config’d by adding a data attribute to the fixed sticky element, e.g. data-fixedstickyfudgetop="65" will start sticky behaviour 65px AFTER the sticky container has hit the top of viewport.
|
I started to merge this to have a look but some of the tests are failing. Can you patch that up? |
|
Hi Zach, Thanks for giving it a go. I'm in the process of building a bigger PR with full sticky sidebar support http://codepen.io/pixelthing/pen/wBGwVK (I just need to check for memory and destroy() compatibility) so I could either patch this one up or get the bigger one ready, depending on whether you prefer the small steps or less PRs. Cheers! |
If multiple sticky instances existed and one was “destroyed”, the script would remove the scroll event binding from all instances and lock any remaining sticky elements in their current position (either initial, sticky or opposite). Now fixed.
|
Sorry for the hassle - I've updated my fork with docs, demos and new features (that also happen to address some of the existing feature requests - although I know you're also working on them in a separate branch). As soon as I've gone through the tests and figured out what I need to do with them, I'll swap to another PR and kill this one. |
|
@pixelthing as bonus I just tested your version and it seems to fix #44 |
|
Really sorry this never made it in. Closing all the PRs—this plugin is now deprecated: https://github.com/filamentgroup/fixed-sticky#-this-plugin-is-deprecated- |
Hi, this is a modification specifically to allow the stylesheet to make layout decisions depending on the capability of the browser and outcome of the polyfill.
It allows devs to style elements for three eventualities:
position:stickysupport is possible (results in no CSS class added to document)position:stickysupport is available (results infixedsticky-nativeclass added to document)position:stickysupport is available - or is chosen over native support (results infixedsticky-polyfilledclass added to document)This is done by adding one class if native support is detected, and a second if the polyfill activates(1) an implementation of fixedsticky. If the dev chooses to substitute native implementation with the polyfill (by fixing the test and re-initialising), both the native and the polyfill classes are added.
I've tried to add and remove classes in a way consistent with how the existing code deals with
fixedsticky-withoutfixedfixed, and to remove the class indestroy().Lastly, telling the stylesheets that native support is available also means a dev might not need Modernizr (or at least a custom build - or grunt-modernizr - to compile a sticky test in). Bonus!
Notes:
(1) Note that just initialising the polyfill is not enough to add
fixedsticky-polyfilled, the implementation does require the sticky element has atop:Xorbottom:Xthat determines if it is activated or not. This meant packaging the top/bottom position test into a method, where it was a one liner before.