Add a destroy method

[oskarrough]

It would be handy with a destroy method. A use case could be to disable snapping for touch devices.

[benoitpointet]

For this use case, just dont enable scrollsnaping if on touch device.

Am Montag, 14. April 2014 schrieb Oskar Rough Mosumgaard :

It would be handy with a destroy method. A use case could be to disable snapping for touch devices.

— Reply to this email directly or view it on GitHubhttps://github.com/benoitpointet/jquery-scrollsnap-plugin/issues/16 .

Liip FR +41 26 422 2511 http://liip.ch

[oskarrough]

Ok fair enough, wrong use case.

I would like to disable scrollsnapping for screens smaller than X (for design reasons). I'd write a PR if I knew how to implement a destroy method.

[nitrokev]

Sorry, this might be a stupid question, but how do you disable for touch/mobile devices?

[benoitpointet]

I would like to disable scrollsnapping for screens smaller than X (for design reasons). You're right that with CSS, changing the screen size (like rotating the device) will impact on the CSS without page reload (thanks to media queries). This plugin is not yet as powerful as that. Will digg into the issue.

@oskarrough Do you know of any jQuery plugin that reacts to screens or devices dependently?

[benoitpointet]

Sorry, this might be a stupid question, but how do you disable for touch/mobile devices?

@nitrokev For this use case, just dont enable scrollsnaping on touch devices.

[benoitpointet]

@oskarrough I dug into the screen size issue. Basically for dynamic response to screen size I'd use a plugin like https://github.com/bfintal/Selector-Query to add specific classes to snapping elements depending on their size (probably varying with screen size). Then target those size-specific classes.

[okwme]

i'm adding content to the page dynamically and need the new content to use scrollsnap. it's not working though because i think i need to destroy and rebuild the scrollsnap. do you know a workaround?

[benoitpointet]

No workaround indeed. It's a pity since your use case is interesting. Cannot promise any update. b.

[frmrstnmnts]

Just wanted to second the notion of a destroy method for the same reason, would enhance the functionality of scrollsnap a lot in building responsive websites. Otherwise, great work!

[benoitpointet]

Ok this has of high priority then. I just need to understand a lot more.

Why? because adding a destroy function won't be trivial. This plugin is structured in an old way which does not easily to add destroy functionality (could pass the message through the options).

So please explain more:

• @frmrstnmnts and @oskarrough : what's the case for destroying rather than testing before instanciating?
• @billyrennekamp : in the case of dynmically adding content, do you had content on which snapping should occur or rather scrolling content?
• would you all see conditional snapping as a possible alternative ... something like a predicate function that is run before the snap match finding algorithm starts to decide wether it should run or not?

[okwme]

it's not actually dynamically added content that causes problems for me--i think that was an earlier post form someone else. mine becomes jittery upon resize. i haven't had time to look into the resize functions already part of scrollsnap but maybe the destroy method could be avoided if the bug there was found.

On Thu, Sep 11, 2014 at 10:24 PM, Benoît Pointet [email protected] wrote:

Ok this has of high priority then. I just need to understand a lot more.

Why? because adding a destroy function won't be trivial. This plugin is structured in an old way which does not easily to add destroy functionality (could pass the message through the options).

So please explain more:

• @frmrstnmnts https://github.com/frmrstnmnts and @oskarrough https://github.com/oskarrough : what's the case for destroying rather than testing before instanciating?
• @billyrennekamp https://github.com/billyrennekamp : in the case of dynmically adding content, do you had content on which snapping should occur or rather scrolling content?
• would you all see conditional snapping as a possible alternative ... something like a predicate function that is run before the snap match finding algorithm starts to decide wether it should run or not?

— Reply to this email directly or view it on GitHub https://github.com/benoitpointet/jquery-scrollsnap-plugin/issues/16#issuecomment-55322683 .

billyrennekamp.com

[IvanBrkicNeuralab]

You can use this to destroy it: $(document).unbind('scrollstop');

see all events bound to document: $._data($(document)[0], "events")

[frmrstnmnts]

@benoitpointet, for me personally i'm having issues upon resizing the browser in use with pagescroller - jittery movement of images. I'm currently using scrollsnap to snap to sections 100vh which i'm pretty certain is throwing it off.

a destroy function might allow me to destroy the instance upon resize, and then reinitialise it again after. I'll give $(document).unbind('scrollstop'); a go though, hopefully this can fix this bugginess!

[benoitpointet]

@frmrstnmnts really sorry about that jittery movement. Any URL where I could see that happen myself. I'm still unsure about the destroy in your case, wouldn't you rather want some kind of reconfigure() instead?

[frmrstnmnts]

@benoitpointet no need to be sorry, most likely, i've done something wrong (i'm still quite new to javascript).

I'm not sure if this will help you, but see this page for an example: http://andrew-ireland.com/craft_project.html

It works well, however if the user resizes the browser scrollsnap can cause some weird movement. Perhaps you may be aware of another method I could use to prevent this behaviour.

Thank you for your concern!

[IvanBrkicNeuralab]

@frmrstnmnts you are doing this:

$(document).ready(function() { $(document).scrollsnap({ snaps: '.section', proximity: $(window).height() * 0.35, easing: 'easeInOutSine', duration: 350, });

So, on document load it gets window height and saves it a a number. That means when you resize the screen it does not calculate the proximity again. Proximity remains the same as it was on load (in pixels). what you can do to make sure it gets calculated on resize is to put this inside your js:

$( window ).resize(function() { $(document).unbind('scrollstop'); $(document).scrollsnap({ snaps: '.section', proximity: $(window).height() * 0.35, easing: 'easeInOutSine', duration: 350, }); });

[frmrstnmnts]

thank you for your reply @ivanbrkicNRLB!

I've attempted your fix – unfortunately however, this causes the jittery movement from scrollsnap calculating the height to become worse - rather than some jittery movement whilst it calculates, the addition of this resize script completely locks up the scrollbar and causes the page to freak out.

I've updated the live index with your script embedded so you can see what i mean if it interests you. see here (click on 'order' first): andrew-ireland.com

[IvanBrkicNeuralab]

Try this:

var timer; function onResize(){ $(document).unbind('scrollstop'); $(document).scrollsnap({ snaps: '.section', proximity: $(window).height() * 0.35, easing: 'easeInOutSine', duration: 350, });

} $(window).bind('resize', function(){ timer && clearTimeout(timer); timer = setTimeout(onResize, 300); });

[frmrstnmnts]

no luck with that code @ivanbrkicNRLB, however i managed to remove the jittery scrollsnap issue by considering your timeout idea. By adding an extra if condition to my window on resize statement so to prevent it from firing more than once / or if pagescroller was already initiated the jittery issue has been resolved.

So a word of warning to anyone else who experiences any jittery scrollsnap calculation – check your window resize events!

Thanks for your support though! You've been a huge help! :100 :+1 :)