http://bugs.jquery.com/ticket/10067#comment:1

Yeah, i think of that guy from time to time. 😭

Come now, Rick. You can't be suggesting that it wasn't worth investigating. The user had provided clear cases where interactive solved a real world problem. I even believe we could have kept this in and ultimately would've been ok and gotten some benefit. It even lead @dmethvin And I to discover some other bugs that will be affecting users when IE10 comes out, so it's not a complete wash. Also, I learned exactly what conditions IE fails on interactive that we can bring forth to Microsoft. Perhaps I need to learn to be less willing to unleash experiments to users, but I stand by the idea that jQuery should be exploring these things, but perhaps without the same gusto I put forth.

Science does not forward without heaps. - Hubert Farnsworth

@mikesherov <3

Group hug!

Yeah, I'm not bugged by it. It's funny that we all were negative-to-meh on it originally, when you look back through the thread.

1.8 Vote: 3 Yes 1 No 2 Abstain

The sole no? ME

Can anyone explain why was pull#901 retreated?
I'm using a similar code and would really like to know if there is a a problem with it,
Thanks!

@vadimzak http://bugs.jquery.com/ticket/12282#comment:15

Thanks @mikesherov,
But if I understand correctly, comment #15 (and below) state that only IE has the premature .readyState == "interactive" problem, so what was wrong with the old "(doc.attachEvent ? doc.readyState == 'complete' : doc.readyState != 'loading')" line? it should have made all IE versions wait for 'complete' and all other sane browsers wait only for 'loading' and thus fire as early as possible, am I wrong?

@vadimzak
Isn't your example the same as browser sniffing? You are relying in a browser's different behavior to test another completely not related oO
That could be the reason they don't use this code...

It is a valid assumption @FagnerMartinsBrack, but in the same DomReady-related code you can find attempts to catch scrolling exceptions (or the lack of them) to detect when some versions of IE have loaded the DOM,
So I don't believe browser sniffing should be an absolute taboo, especially if it is the only way to get the required result.

I was wondering if the development team actually found cases where the previous version (before this fix) did not perform as expected, and if so - couldn't some browser-sniffing be used to make the event better (fire earlyer) on non-IE browsers?

@vadimzak, sure. At the time, we weren't really ready for it, and we had also made changes to allow $(document).ready() to be a true deferred... that is it could execute synchronously.

In practice, $(document).ready() was always async because of the order in which the events fired, and when we switched to readyState !== "loading" there were cases where it would execute synchronously, throwing off developer expectations.

At this point, we could probably try again, and it's probably safe in your own code, it just wasn't ready to be deployed to 60% of the internet ;-)

I don't see any reward for this risk, we tried it once and it was a mess. Let's see some proof that firing this event earlier leads to faster pages, and that it doesn't cause messy regressions. I just had to deal with chasing this problem down for a client a month ago, they were using 1.8.0 and this was causing all kinds of strange behaviors.

Whoa, a lot happened with my bug. Or "bug". I'm sorry guys, couldn't have foreseen that.

On the other side, right now I'm waiting for 10 minutes for document.ready due to ever loading iframe (it isn't crafted or special in any way, that just happens from time to time in FF and Opera).

Looks like I'm going back to manual check for "interactive".
Sorry again.