@Shade, it was broken but I have updated it and it works like a charm.
About the leak, that scope is parsed but never used/referenced via IE (so no
leaks), I don't think even in the unpatched IE6 that little single scoped
function will be a problem, compared with the total amount of scripts that
does not care at all about these kind of leaks (never seen a library with
hundreds of null assignment at the end for non IE functions, specially in a
features detection script where you cannot even know which function should
be removed)
Feel free in any case to use your "bigger" version if you think it's worth
it.
I did not invent anything here, it is just a proof of concept with a
manually minified suggestion ;-)
On Thu, Nov 19, 2009 at 12:10 AM, Shade <get...@gmail.com> wrote:
> Here's my minified version... it's *slightly* larger at 209 characters
> (vs 195), but it works, and bonus, it doesn't use a memory-leaky named-
> function-expression:
>
> (function(a,b,c,d){if(a[b]==null&&a[c]){a[c](d,function()
> {a.removeEventListener(d,arguments.callee,false);a[b]
> ="complete"},false);a[b]="loading"}})
> (document,"readyState","addEventListener","DOMContentLoaded");
>
> Thanks for the inspiration, though, Andrea!
>
> --Kyle
>
>
>
> On Nov 18, 5:55 pm, Shade <get...@gmail.com> wrote:
> > Ummm... ammendment: The complete snippet works:
> >
> > if(document.readyState == null && document.addEventListener){
> > // on DOMContentLoaded event, supported since ages
> > document.addEventListener("DOMContentLoaded", function
> > DOMContentLoaded(){
> > // remove the listener itself
> > document.removeEventListener("DOMContentLoaded",
> > DOMContentLoaded, false);
> > // assign readyState as complete
> > document.readyState = "complete";
> > }, false);
> > // set readyState = loading or interactive
> > // it does not really matter for this purpose
> > document.readyState = "loading";
> >
> > }
> >
> > But, the minified/re-arranged snippet (the 195 chars) Andrea provided
> > does not work. Do you own minification and you'll be fine, just don't
> > use what he posted.
> >
> > --Kyle
> >
> > On Nov 18, 5:44 pm, Shade <get...@gmail.com> wrote:
> >
> >
> >
> > > I have confirmed in this test:
> >
> > >http://test.getify.com/archive/dynloadjquery/index6.html
> >
> > > ...that Andrea's proposed snippet does in fact "patch a page" to have
> > > a proper readyState, assuming of course the snippet itself is
> > > guaranteed to run before domready. The test includes it in a manual
> > > script tag at the bottom of the page, and then you can click a button
> > > to dynamically load jquery into the page, then click the other button
> > > to see if jquery's internal ready flag is set properly or not.
> >
> > > I used a patched version of jQuery 1.3.2 (1.3.2.1 I called it) which
> > > only has the changes to the bindReady() function as they appear in
> > > GitHub right now (namely, the additional check for the
> > > document.readyState which John landed as a result of that previous bug
> > > I linked to earlier in this thread).
> >
> > > I tested this just now in both FF3 and 3.5 (both windows), and it
> > > works fine.
> >
> > > That means, that at least for now, even though patching jquery itself
> > > doesn't do much or help anything with the problem of being able to
> > > lazy-load jquery core, which my biggest concern/use-case, you can
> > > still "patch" a page to be able to lazy-load jquery. That's definitely
> > > an improvement.
> >
> > > It also means that any code that relies on jquery's test (such as code
> > > that uses document.ready) is now also safe to lazy load right along
> > > with jquery core itself, as long as doing so in a "patched" page.
> >
> > > I'm satisfied that this being included in LABjs will allow users to
> > > adequately load jquery.js on-demand without fear of the isReady checks
> > > failing later. The only caveat then will be that LABjs has to make
> > > sure it's there before dom-ready, but for all the use cases I care
> > > about, it's quite unlikely that people will use some other loading
> > > technique to lazy-load the Loader itself.
> >
> > > --Kyle
> >
> > > On Nov 18, 5:03 pm, Már Örlygsson <mar.orlygs...@gmail.com> wrote:
> >
> > > > Am I right to think that there's a similar problem with the
> > > > window.onload event?
> > > > i.e. if you're too late in binding a handler to window.onload, it
> will
> > > > never fire?
> >
> > > > --
> > > > Már- Hide quoted text -
> >
> > > - Show quoted text -- 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<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.
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=.
