@Andrea- I guess I'm confused as to how this bit of code fixes the
problem if it's not intended to be a patch inside of jquery?
Is it because this bit of code forces there to be a
document.readyState of "loading" if we're in a browser that doesn't
already have that property?
Then, as I understand it, since your bit of code *would have to be*
guaranteed to always be on the page before domready, then it'll
basically come along and move the readyState to "complete" once the
domready really does happen.
Then, ostensibly, jquery comes along and will always see the
document.readyState property, so it should be able to use it no matter
what browser we're in?
Do I have that sequence and usage correct? It's an interesting
approach. I may be able to stick that in LABjs to try and help the
situation. But then again, the problem is forcing/guaranteeing that
this snippet of code is always run before the domready. Maybe just
always include that in your page templates at the bottom, in an inline
<script> tag? Hmmm....
On Nov 18, 11:51 am, Andrea Giammarchi <andrea.giammar...@gmail.com>
wrote:
> John, I have never said here or in my post jQuery should include that script
> ... it's the other way round.
> I perfectly understand jQuery cannot be dynamically loaded with that script.
> Indeed, what I have said is that web pages should include that script by
> default before any other script.
> In this way jQuery, as many other libraries based over that check, won't
> suffer that problem anymore.
>
>
>
> On Wed, Nov 18, 2009 at 5:33 PM, John Resig <jere...@gmail.com> wrote:
> > Andrea -
>
> > Your solution doesn't work for dynamically loaded scripts. If you load
> > jQuery after both the DOMContentLoaded and window.onload events have fired
> > your script will be stuck in a permanent "loading" state.
>
> > I'm still looking for a solution that'll work with dynamic loading (which
> > is what makes document.readyState so enticing).
>
> > --John
>
> > On Wed, Nov 18, 2009 at 12:21 PM, Andrea Giammarchi <
> > andrea.giammar...@gmail.com> wrote:
>
> >> Dude, you wrote basically everything I have said in my post (my precedent
> >> reply)
> >> Put this in the top of your scripts and imho problem solved:
>
> >> (function(s,o,l,v,e,d){if(s[o]==null&&s[l+e]){s[v+e](d,function
> >> e(){s[l+e](d,e,!1);s[o]="complete"},!1);s[o]="loading"}})(document,"readyState","add","remove","EventListener","DOMContentLoaded");
>
> >> I am using this trick and some revisited DOMContentLoaded emulation for a
> >> tiny event based library I cannot show right now since it is incomplete but
> >> above trick has been tested in every Firefox I could find here.
>
> >> Regards
>
> >> On Wed, Nov 18, 2009 at 3:44 PM, Shade <get...@gmail.com> wrote:
>
> >>> I just want to say that I still think that the "document.readyState"
> >>> problem is an issue that needs further addressing than what jquery is
> >>> planning to ship right now. This bug brought this topic up a few
> >>> months back:
>
> >>>http://dev.jquery.com/ticket/4889
>
> >>> At the time, as John said, we thought it would be "ok" the solution
> >>> that is now in, because FF3.5 was going to finally include
> >>> document.readyState, and so the number of browsers affected by the
> >>> problem by the time jquery released again would be minimal... FF3 and
> >>> below has to be a dwindling number now.
>
> >>> But, now that we know that FF 3.5 still has this problem, and it only
> >>> *may* end up FF3.6, and that jquery is releasing soon, I think there
> >>> will be a lot of people still affected by this problem. FF3.5 will be
> >>> around for a non-trivial amount of time, even if FF3.6 released today
> >>> (which we know it will still be a little while).
>
> >>> Here's the primary reason I consider this an issue worth more effort:
> >>> I have been pushing this tool I built called LABjs (http://labjs.com)
> >>> which is a parallel script loader. It's getting a lot of good support
> >>> and reviews so far, but it suffers one major problem (and almost all
> >>> loaders have this same issue): it can't be used safely to load scripts
> >>> like jquery, because if it happens to load the script after the page's
> >>> domready, then all $(document).ready(...) related code will sit idle
> >>> and never be fired! This is a major achilles' heel for any script
> >>> loader.
>
> >>> Whether you like LABjs or not, or plan to use it or something like it
> >>> or not, there are starting to be more and more places where people are
> >>> trying to accelerate the loading of their pages through various
> >>> techniques like dynamic script loading (XHR, etc), meaning it's going
> >>> to more and more likely that jquery gets added to a page in some other
> >>> way than through a normal blocking script tag. This means that this
> >>> problem with it detecting domready will get more and more obvious
> >>> until we find a way to solve it.
>
> >>> Every time I have given a talk about LABjs over the last couple of
> >>> months, I've mentioned this caveat but said "But, at least with the
> >>> next jQuery this will be fixed."
>
> >>> But, now hearing that even with FF3.5 it won't be fixed yet, I think
> >>> we need something better, even if we just do some sort of temporary
> >>> hacks for a release or two until we have stable browser base where
> >>> this works.
>
> >>> I know that jQuery doesn't officially guarantee this usage.... but
> >>> that I think is a troublesome blindsight to just ignore. It's a
> >>> perfectly valid use-case for jquery (think about bookmarklets, etc),
> >>> it's not at all documented very well that this problem exists, and the
> >>> web is moving to more and more of various different tricks to load
> >>> things in different ways, which *will* expose the problem even more.
>
> >>> I think we should run some tests to prove whether or not Andrea's code
> >>> solution addresses this problem for FF or not. Or we could revisit the
> >>> code from the bug I linked, which was actually from SWFObject, and see
> >>> if it can provide a temporary hack fix. Or we can find something
> >>> else.
>
> >>> But I just don't think there simply is no answer -- there has to be a
> >>> way for jquery to detect if domready is already passed. We may just
> >>> need to be more creative and a little more accepting of hackiness for
> >>> the time being. I know there won't be a nice elegant solution to this
> >>> problem, but I think doing nothing and just saying "sorry that's not
> >>> supported" is going to become more and more a problem the longer we
> >>> don't address it.
>
> >>> --Kyle
>
> >>> On Nov 17, 2:23 pm, Andrea Giammarchi <andrea.giammar...@gmail.com>
> >>> wrote:
> >>> > On Tue, Nov 17, 2009 at 8:15 PM, John Resig <jere...@gmail.com> wrote:
> >>> > > Oh, just to mention, regarding your solution snippet - it doesn't
> >>> really
> >>> > > solve anything (especially not for us).
>
> >>> > it does not really solve anything? That's probably why I had to
> >>> implement
> >>> > for a little project I am working on right now ...
> >>> > Anyway, I posted why it make sense to implement out of the box:
> >>>http://webreflection.blogspot.com/2009/11/195-chars-to-help-lazy-load...
>
> >>> > Regards
>
> >>> --
>
> >>> You received this message because you are subscribed to the Google Groups
> >>> "jQuery Development" group.
> >>> To post to this group, send email to jquery-...@googlegroups.com.
> >>> To unsubscribe from this group, send email to
> >>> jquery-dev+unsubscr...@googlegroups.com<jquery-dev%2bunsubscr...@googlegroups.com>
> >>> .
> >>> For more options, visit this group at
> >>>http://groups.google.com/group/jquery-dev?hl=.
>
> >> --
> >> You received this message because you are subscribed to the Google Groups
> >> "jQuery Development" group.
> >> To post to this group, send email to jquery-...@googlegroups.com.
> >> To unsubscribe from this group, send email to
> >> jquery-dev+unsubscr...@googlegroups.com<jquery-dev%2bunsubscr...@googlegroups.com>
> >> .
> >> For more options, visit this group at
> >>http://groups.google.com/group/jquery-dev?hl=.
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "jQuery Development" group.
> > To post to this group, send email to jquery-...@googlegroups.com.
> > To unsubscribe from this group, send email to
> > jquery-dev+unsubscr...@googlegroups.com<jquery-dev%2bunsubscr...@googlegroups.com>
> > .
> > For more options, visit this group at
> >http://groups.google.com/group/jquery-dev?hl=.- Hide quoted text -
>
> - Show quoted text -
--
You received this message because you are subscribed to the Google Groups
"jQuery Development" group.
To post to this group, send email to jquery-...@googlegroups.com.
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en.
