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//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 notifications@github.com
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
#16 (comment)
.

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?