Replying to [comment:6 jaubourg]:
> I know I can rely on it. But, in this case, according to the documentation, which was so clear for me on this point, the "second alert"'s callback should be performed when it was registered, because the DOM is already initialized. > > What I mean is: '''The order of execution is right, but jQuery is queuing something when it shouldn't. No, the order of execution is right because''' jQuery is queueing. ''Ready handlers are executed in the order they were added''. The handler alerting "second alert" is added last (third) and is executed last. It's simply impossible to ensure the behaviour without queueing because you need to let the second handler execute before you execute the third one. Please note that this is all done synchronously. So the handler is effectively called "immediately" (no asynchronous delay), just after all other currently bound handlers so that order of execution is consistent. Then again, ''it's just not the order you were expecting'' but it is expected behaviour. The documentation is just not clear enough.
Well, I got your point. Here in Brazil we are used to say "for each case, one case", which means that each situation is different from another.
I think this current behaviour is useful for several situations. But sometimes the other is needed, for example, for me. In my case, I needed the callback to be performed immediately (without queueing), and my code didn't know that it was already in a "ready block".
So, we could think of allowing the developer to configure this behaviour, that is, immediate calls with or without queueing.