I have a box that takes an input, then uses the scrollable's seekTo method on keyup to go to a particular slide. The problem is that if someone types quickly the scrollable gets a large queue and it takes a while for the animation to stop.
What I would like is on keyup the previous animation stops (unless the input is empty) and the new animation starts. I've tried putting .stop() in various places, but nothing seems to work.
Here is a fiddle of something similar to what I'm doing: http://jsfiddle.net/QaMZH/
Putting a number in the box (ex:1) then changing it to another number (ex: 2) will animate the scrollable to that slide number, but changing the numbers quickly queues a bunch of animations that can take a while to finish.
I had the same problem, and after searching for more detailed documentation and fail, I just dug into the code.
It turns out that all you need to do is call this before .seekTo():
api.getItemWrap().stop(true, false);
api.seekTo($(this).val(), 1000);
where getItemWrap() returns the target jQuery element where the animation takes place.
See http://jsfiddle.net/QaMZH/4/ how the modified version works.
This works because .seekTo() method calls the jQuery .animation() method on the elements, and you can cancel jQuery animations any time with .stop().
Related
This onscreen plugin is meant to add classnames only to elements when they are within the viewport, however it seems to be adding the classnames as soon as the page is loaded which isn't what's meant to happen.
$(function() {
setInterval(function() {
$("#star").filter(":onScreen").addClass('animated bounceInRight');
}, 0)
})
I'm using it within this plugin which, is a book effect plugin and I think it conflicts with onscreen in some way: http://pastebin.com/UmyJ6zBW This plugin requires different sections on one page for it to work. Onscreen works when used within the first section but breaks when in others that aren't actually on view. How do I fix this?
You can do one of three things.
Don't bother. In general you don't need to worry about the style of elements that are not in view.
Use setInterval() but reduce the interval to the minimum acceptable value but no less than about 20 ms.
[preferred] Establish an event handler that fires in response to whatever causes your #star element to be moved on/off screen.
For the third approach :
jQuery animations provide for a step callback which fires as each animation step is executed.
As scrolling the document will also cause elements to come in/out of view, you probably also want to a scroll handler.
With care, you should be able to write a single function and use it for both purposes.
I've two (but maybe more) DIVs, animated through jQuery; so now they are running all over my screen, following pseudo random paths.
I want to fire an event every time part of a DIVoverlaps part of another one. Any ideas?
You could use something like this http://sourceforge.net/projects/jquerycollision/ and check for collisions after each animation step.
Okay, so, I have a bit of a strange situation which I have encountered multiple times. I'm looking for a simple/the best solution, NOT the overcomplicated solution I used before (and have since forgotten).
You see, I have a slideshow. I also have a couple of buttons that float on top of the slide show (visible here: http://marsxplr.com/view-13378)
Now, I have these buttons appear when the user's mouse goes over the slideshow. However, the minute the user's mouse goes over the buttons, mouseleave is called (even though the mouse is still technically over the slideshow!). This causes the buttons to disappear whenever the mouse goes over them, which is obviously not something I would like to happen.
I solved this by then making each button re-show its self whenever it receives a mouseover.
But now, we have a problem...
The button is on the very edge of the slideshow. That means that when mouseleave is called, one of two things happened:
A:The mouse went off of the button but not off of the slideshow, and mouseEnter got called on the slideshow meaning that no action should be taken because slideshow will eventually take care of hiding the button in its mouseleave.
B: The mouse simply left the slideshow and button altogether meaning that we should HIDE the button!
So my question is, how do I tell the difference between these two possibilities? Yes, yes, one solution would be to just always make the button hide its self -- and rely on the slideshow re-showing the button... But I am worried that the slideshow onmouseenter will be called BEFORE the button onmouseleave on certain browsers! This could cause issues as you can probably tell. In fact, thinking about this, I am already susceptible to this. For instance, if the mouse goes from the slideshow to the button, and the onmouseleave for my slideshow is called AFTER the onmousleave causing the button to still dissapear...
So, long story short, I need to know one of these two things:
Is there a guaranteed order in which these events are called?
Or is there a way to tell where the mouse actually WENT when mouseleave is called?
As you can see in my example above, I am using mootools, so a mootools solution is fine. It would, however, be interesting to see a vanilla-js solution as well.
EDIT:
My buttons are floated and on a separate z-index, so the standard operation for a parent-child DOM relationship does not occur
No such problem with standard DOM events.
As for the order, it bubbles from the deepest elements up to the document root.
There's also an optional (see the false param in the code below) capture phase, when the order is reversed. From the root to each inner element under the cursor (for mouse events).
To check on which inner element of the original element the event actually occurred, you can inspect the target property of the event object:
el.addEventListener('mouseout', function (e) {
var target = e.target;
if (target.classList.contains('whatever')) {
// Do something
}
}, false);
As per Georges Oates Larsen's comment, there's also relatedTarget, designed specifically for events involving several elements.
Take a look at this jsfiddle
http://jsfiddle.net/zB2Td/5/
Animation is triggered although .animate class is added after changing the dimensions.
If you uncomment the second line from the end transition won't start as it should.
Why does this code work like that?
What is a proper way to add .animate and not trigger transition on the previous changes.
Thanks!
To my understanding, what's happening is that the call to box.width() counts as a "Read" operation, as defined by this post. It forces the browser (webkit anyway) to re-layout (aka reflow) the DOM. Without this call, the browser never "knows" that the box was 200x200 prior to .animate being added, and it assumes the box started out at 100x100.
So, here is how the slideshow looks.
a[b]cde
In this example, b is the visible part of the slideshow. When b is visible, you can't see a,c,d, or e.
Is it possible that when b is showing, that you can see a preview, or overflow, of the right quarter of a and left quarter of c? These previews would essentially be next and previous buttons that have a translucent background.
I don't want for just the one active slide to show, I want to be able to see a left quarter of the before slide and right quarter of the after slide just before they come in or after they leave, respectively.
I don't know what part of the cycle plugin I need to rewrite or code in order to do this. Is it too hard or difficult to accomplish with the cycle plugin?
The cycle plugin gives numerous callbacks, such as before and after which can probably be used to to add the behavior you described. They are all outlined here: http://jquery.malsup.com/cycle/options.html
The before callback is called before a transition happens and is passed currSlideElement and nextSlideElement as parameters.
Using these parameters, you can get a reference to the image that will appear next, or has just appeared and do anything you wish with it. This may mean cloning it and displaying it next to the slideshow.
I'm confident that some combination of before and after callbacks will make this behavior possible.