Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Slight confusion with description of effect function behaviour #654

Open
derwaldgeist opened this issue May 29, 2015 · 1 comment
Open
Assignees

Comments

@derwaldgeist
Copy link

Hi there,

I'm a newbie who is reading through your (excellent) description, thanks for your good work!

At one point I stumbled, and I would like to share my confusion with you.

On section http://learn.jquery.com/effects/intro-to-effects/#doing-something-after-an-animation-completes, there is the statement:

"A common mistake when implementing jQuery effects is assuming that the execution of the next method in your chain will wait until the animation runs to completion. [...] It is important to realize that .fadeIn() above only kicks off the animation. Once started, the animation is implemented by rapidly changing CSS properties in a JavaScript setInterval() loop."

Later on the same page, in section http://learn.jquery.com/effects/intro-to-effects/#delay-, there is an example that seems to contradict what we've learned above:

// Hide all level 1 headings over half a second; then wait for 1.5 seconds
// and reveal all level 1 headings over 0.3 seconds
$( "h1" ).hide( 500 ).delay( 1500 ).show( 300 );

I first thought, the description might be a mistake, but according to the API documentation, this is exactly how delay() behaves. My only explanation to this is that jQuery internally checks if chained function calls refer to animations as well - and if so, chains these animations as well, probably using an animation queue. It would be much clearer if this would be explicitly stated on that page to avoid reader's confusion.

@arthurvr
Copy link
Member

They're indeed added to the queue. When reading the article on queues (which is one of the next ones) I think that becomes clear.

So what we're saying there is in fact correct though I'm +1 on adding a brief note to clarify it for people that don't even know what a queue is (very likely when people are reading that page).

Thanks for reporting this issue! Any hints for us on how to clarify things are welcome, always :)

@arthurvr arthurvr self-assigned this Jun 6, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

No branches or pull requests

3 participants