Hello,
I was also facing the same problem that i am not able to get the
document.readyState property in the FF and this thread has solved my
problem.
Thanks a lot,
Kusum
On Nov 18 2009, 1:15 am, John Resig jere...@gmail.com wrote:
Oh, just to mention, regarding your solution snippet - it
I don't understand why you are writing code like this in a developer
group... some ongoing competition.
It is not clear if you have trade secrets or just don't want others to
see the errors in it. ;-)
Do you want to talk about them and discuss them or is this a way of
just posting a snippet, for
Here is a snippet much longer, and hope a bit clearer, than the one
Andrea wrote:
(function(global) {
if (typeof document.readyState == 'undefined') {
HTMLDocument.prototype.
__defineGetter__(readyState, function () { return
domReady; });
HTMLDocument.prototype.
@Shade, just to inform you I have removed the named function expression
reusing a variable:
(function(s,o,l,v,e,d){if(s[o]==nulls[l+e]){s[o]=loading;s[l+e](d,l=function(){s[o]=complete;s[v+e](d,l,!1)},!1)}})(document,readyState,add,remove,EventListener,DOMContentLoaded)
Regards
On Thu, Nov 19,
As I mentioned before - I'd *love* to have a solution for this. Any working
solution for Firefox 3.6 will be happily accepted.
--John
On Wed, Nov 18, 2009 at 10:44 AM, Shade get...@gmail.com wrote:
I just want to say that I still think that the document.readyState
problem is an issue that
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
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
@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
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
On Wed, Nov 18, 2009 at 7:51 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
1. since it is extremely slow
2.
I meant since it is extremely light ... Freudian typo :D
--
You received this message because you are subscribed to the Google Groups
jQuery Development group.
To
1. 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,
On Wed, Nov 18, 2009 at 8:12 PM, Shade get...@gmail.com wrote:
@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
Put this in the top of your scripts and imho problem solved:
(function(s,o,l,v,e,d){if(s[o]==nulls[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);
Thanks Andrea, for this nice hack.
I'll likely use it
P.S. I'm curious, is there really no way - not even some, nasty,
messy, setTimeout-based, icky one - for jQuery to guarantee that
document.ready is always triggered?
None that I know of, no. :-/
--John
--
You received this message because you are subscribed to the Google Groups
jQuery
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
--
You received this message because you are subscribed to the Google Groups
jQuery Development group.
To post to this
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?
That is correct.
--John
--
You received this message because you are subscribed to the Google Groups
jQuery Development
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
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
Shade,
you used the explanation rather than the minified version (which I am gonna
test now 'cause it worked 'till now)
the problem is that with the explained code you gonna create a global
DOMContentLoaded function in Internet Explorer and its lovely buggy JScript
engine (function expressions
Right, I wronte v+e rather than l+e and vice-versa, post updated, new script
is here:
(function(s,o,l,v,e,d){if(s[o]==nulls[l+e]){s[l+e](d,function
e(){s[v+e](d,e,!1);s[o]=complete},!1);s[o]=loading}})(document,readyState,add,remove,EventListener,DOMContentLoaded);
it works!
On Thu, Nov 19, 2009
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]==nulla[c]){a[c](d,function()
{a.removeEventListener(d,arguments.callee,false);a[b]
@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
22 matches
Mail list logo
