@Andrea -- i highly doubt anyone is loading jquery plugins which do
their own dom-ready detection... i'm sure that almost all jquery code
is written against $(document).ready(...) if anything. So fixing the
lazy loading of plugins is much less of a concern to me (and probably
most people) as fixing the lazy loading of jquery core itself. Your
snippet in the main page will address that, at least in some main use
cases that are important to me.
You asked for a use-case for "lazy-loading" jquery... there are
plenty. Bookmarklets is one... but my main one, as I mentioned, is the
use of LABjs to load scripts in parallel. This type of script loading
optimization has the unfortunate effect of sometimes causing the
domready to happen so quickly that jquery hasn't yet loaded onto a
page, which causes jquery to hang waiting for dom-ready forever.
So, putting your fix into LABjs should fix that problem.
--Kyle
On Nov 18, 1:51 pm, Andrea Giammarchi <andrea.giammar...@gmail.com>
wrote:
> Shade, my code should be before any other script and outside whatever
> library but in every page.
> I created the 195 chars version (195 bytes it cannot be such big deal in the
> 50Kb per library era) to make the template inline solution possible as well,
> if you like it.
>
> That script guarantees these things:
>
> 1. it will never be executed in Internet Explorer since it is the only
> browser that support readyState since version 5 I guess ...
> 2. it should never executed in other browser with readyState support
> (Chrome, WebKit, Safari, Opera, probably others)
> 3. it does not conflict with itself, the first time it's executed,
> readyState will be different from undefined/null so even if every library
> will use it, there won't be problems
> 4. since except IE events respect orders, if this inline script will be
> the first executed thing ever. It does not matter if other libraries uses
> DOMContentLoaded event, that will act as usual without problems at all
> 5. since it is extremely slow, it does not even require effort in the
> server (ETag or gzip) and it won't slowdown the page load (we include
> massive scripts such Google Analytic I guess who could complain about 195
> extra bytes)
> 6. In the jQuery specific case, if the library will adopt the script, the
> library will make lazy plug-ins load based on $(document).ready(...)
> possible. We need to understand that jQuery as is, is not that kind of lazy
> loaded library since I assume that if a website uses jQuery, everything
> will
> depend on it. Accordingly, this trick inside jQuery will make everything
> else lazy loadable except jQuery itself ... now please find a real case
> scenario where jQuery is lazy loaded ... if any, that has never trusted the
> ready event since it cannot work in any case with the current
> DOMContentLoaded based implementation
>
> In few words now we have nothing, with this script every website based on
> jQuery usage, if integrated into the library, will be able to lazy load a
> lot of other stuff ... pngfix, whatever plug-in/extension when needed.
> I do agree that this is in any case a temporary fix, but if we are realistic
> about my proposed solution, we can considered a "non guaranteed" behavior
> "almost guaranteed", which is again, IMHO, better than nothing.
>
> This is my point of view and jQuery could solve even non jQuery related
> plug-ins based on readyState check.
>
> Side effects:
>
> 1. if a library, plug-in, relies in the readyState sniff, it could behave
> as IE rather than a Firefox library. That library, if created like this, is
> not good in any case since it will fail with the next Firefox release
>
> Regards
>
>
>
> On Wed, Nov 18, 2009 at 7:29 PM, Shade <get...@gmail.com> wrote:
> > @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>
>
> ...
>
> read more »- 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.
