document.readyState 'interactive'

[jimisaacs]

In Safari 5.1 and iOS 5 they have implemented the readyState 'interactive' which seems to be set after the DOMContentLoaded event has fired.

I was wondering if something like this would work, or would it break in previous versions?

ready: function(callback){
    if (document.readyState == 'complete' || document.readyState == 'loaded' || document.readyState == 'interactive') callback();
        document.addEventListener('DOMContentLoaded', callback, false);
        return this;
},

[mislav]

Is this related to #159?

[jimisaacs]

@mislav it does look related in terms of the readyState, but I'm not sure what the issue means by "dynamic script elements".

From what I can see...

• Using Safari 5.1 or iOS 5
• Try to add a ready handler within the body (I tried at the end) and check the readyState and it should be "interactive".
• DOMContentLoaded will have already fired hence sending your ready handler into oblivion.

[jimisaacs]

Ammending that last comment.
It looks to be specifically when you add a ready handler from within another ready handler.
So this way you are sure that the DOMContentLoaded as fired, but the readyState hasn't changed.

Testcase: https://gist.github.com/1228091

[jimisaacs]

This is actually something I believe would be fixed better if Zepto just kept an internal flag of:
domContentLoaded = true | false

Rather than looking at the readyState, simply add a one-off internal listener to DOMContentLoaded, when fired, set the internal flag to true, and remove itself.

When adding ready handlers from the Zepto api, if the flag is false, add the callback as a listener of DOMContentLoaded.
If the flag is true invoke the callback.

Doing it this way decouples Zepto from the implementation of readyState, and just relies on the event.

I may try to get to doing a pull request, but if someone beats me to it, just update this issue thanks!

[jimisaacs]

Hmmm... I am already foreseeing the same issue with my previous idea before I even started.

If the internal listener is added first.
Then 2 subsequent nested listeners from plugins or elsewhere are added.
The last listener fired would be the internal listener, resulting in the same problem.

I'm not sure if using the capture phase works on this event or not, if so the internal could use the capture, while the callbacks use the bubble.
If this event does not bubble, then I guess the only way to work with only the event is with an array of queued handlers (yuck).

[mislav]

Browser's aren't supposed to guarantee the consistent order of event handlers fired. So, if we add an internal domready handler, it's not guaranteed that it will fire first.

Not sure what to do about this issue (and the linked one) yet, but thanks for adding your thoughts here. I'll definitely do something about all this before the next release