Just for the record, because my mail client replied directly to Martin.
On Wednesday 27 August 2014 12:46:45 Martin Grigorov wrote:
> On Wed, Aug 27, 2014 at 12:41 PM, Emond Papegaaij <
>
> [email protected]> wrote:
> > On Wednesday 27 August 2014 11:57:24 you wrote:
> > > Hi Emond,
> >
> > <cut some git diff stats>
> >
> > > > + } else if (type === 'load' && element
> >
> > ===
> >
> > > > window) {
> > > > + jQuery(window).on('load',
> > > > function() {
> > > > + jQuery(fn);
> > > > + });
> > >
> > > I believe this can be simplified to :
> > > jQuery(window).on('load', fn);
> > > Could you please test it ?
> > >
> > > If passed to jQuery (as jQuery(fn)) then I read it as: when window.load
> > > event is triggered add fn as a dom-ready handler.
> > > jQuery will postpone the execution of fn if the DOM is not ready or it
> >
> > will
> >
> > > fire fn immediately if the DOM is ready.
> > > I see no reason for all this. The simpler code should be enough.
> >
> > The reason I wrote it this way, was because this was how it works for
> > other
> > event types (the "try to find the element once the DOM is ready" comment).
> > If
> > it is changed to simply 'jQuery(window).on('load', fn)', the code in 'fn'
> > can
> > be executed before the dom is ready (in case load is triggered before dom
> > ready). This might give problems if your code expects the dom to be ready.
> > This probably won't happen very often, because normally load is triggered
> > after dom ready and the load event is not used that often, but still, it
> > might
> > give some unexpected errors.
> >
> > In the case of AbstractAjaxTimerBehavior it shouldn't matter, because that
> > script does not require the dom to be ready, but other scripts might.
>
> OK. Leave it like this just to be on the safe side.
>
> > Best regards,
> > Emond
