Can script determine if window.onload has already fired?
Matt Kruse
piqued my curiosity. I'm interested to know if the smart people here
have a good answer.
Is there a cross-browser way, in script, to determine if window.onload
has already fired?
If a script is lazy loaded and needs the DOM to be ready, it can
attach to the window's load event. But if that has already fired, then
the script's code will never run. Alternatively, it can just fire its
code inline, but the DOM may not be ready.
Thoughts?
Matt Kruse
Thomas 'PointedEars' Lahn
> There is a discussion going on in the jquery-dev mailing list that
> piqued my curiosity. I'm interested to know if the smart people here
> have a good answer.
>
> Is there a cross-browser way, in script, to determine if window.onload
> has already fired?
>
> If a script is lazy loaded and needs the DOM to be ready, it can
> attach to the window's load event.
But it should not. The loading state of the window has nothing to do with
the loading state of the document. We've been over this.
> But if that has already fired, then the script's code will never run.
> Alternatively, it can just fire its code inline, but the DOM may not be
> ready.
>
> Thoughts?
Smart people use the standards-compliant `onload' attribute instead.
PointedEars
--
Prototype.js was written by people who don't know javascript for people
who don't know javascript. People who don't know javascript are not
the best source of advice on designing systems that use javascript.
-- Richard Cornford, cljs, <f806at$ail$1$8300...@news.demon.co.uk>
Matt Kruse
wrote:
> But it should not. The loading state of the window has nothing to do with
> the loading state of the document. We've been over this.
Fine then, substitute in any other method you prefer.
> Smart people use the standards-compliant `onload' attribute instead.
Could you be more specific?
Matt Kruse
Thomas 'PointedEars' Lahn
> Thomas 'PointedEars' Lahn wrote:
>> Smart people use the standards-compliant `onload' attribute instead.
>
> Could you be more specific?
<body onload="...">
PointedEars
--
realism: HTML 4.01 Strict
evangelism: XHTML 1.0 Strict
madness: XHTML 1.1 as application/xhtml+xml
-- Bjoern Hoehrmann
Matt Kruse
wrote:
> <body onload="...">
Script cannot add itself to this attribute, though.
You're steering away from the real question, anyway. Regardless of
whether you feel it should be used, is there any cross-browser way to
detect if window.onload has already fired?
Matt Kruse
David Mark
> On Nov 19, 1:06 pm, Thomas 'PointedEars' Lahn <PointedE...@web.de>
> wrote:
>
> > <body onload="...">
>
> Script cannot add itself to this attribute, though.
Groan. Script doesn't have to "add itself" to this attribute.
>
> You're steering away from the real question, anyway.
Yes.
> Regardless of
> whether you feel it should be used, is there any cross-browser way to
> detect if window.onload has already fired?
Of course. Attach a load listener (or use the standard onload
attribute). They both do the same thing. One is proprietary and one
is not.
The proprietary window.onload property likely came about so that
scripts in the HEAD could set a load listener to the BODY before the
body is ready.
Now, how to know if the BODY load event has fired? Set a flag, of
course.
David Mark
[...]
>
> If a script is lazy loaded and needs the DOM to be ready, it can
> attach to the window's load event. But if that has already fired, then
> the script's code will never run. Alternatively, it can just fire its
> code inline, but the DOM may not be ready.
>
And what sort of scheme are they working on where their scripts are
unclear about whether the load event has fired? Sounds like a recipe
for disaster to me.
<body onload="loaded = true;">
Or, as mentioned, set window.onload if you think that is a cooler,
more "unobtrusive" solution (despite the inherent drawbacks).
Thomas 'PointedEars' Lahn
> On Nov 19, 3:07 pm, Matt Kruse <m...@thekrusefamily.com> wrote:
>> On Nov 19, 1:06 pm, Thomas 'PointedEars' Lahn <PointedE...@web.de>
>> wrote:
>> > <body onload="...">
>>
>> Script cannot add itself to this attribute, though.
>
> Groan. Script doesn't have to "add itself" to this attribute.
See below.
>> You're steering away from the real question, anyway.
>
> Yes.
No. I was just closing at it at a slower pace :)
>> Regardless of
>> whether you feel it should be used, is there any cross-browser way to
>> detect if window.onload has already fired?
>
> Of course. Attach a load listener (or use the standard onload
> attribute). They both do the same thing. One is proprietary and one
> is not.
But if we assume that, due to the flawed concept, there are only "lazy-
loaded" scripts, there is a chicken-and-the-egg problem with adding a load
listener with scripting. Hence my recommendation to use the `onload'
attribute of the `body' element in the first place.
> The proprietary window.onload property likely came about so that
> scripts in the HEAD could set a load listener to the BODY before the
> body is ready.
Unlikely: <http://docs.sun.com/source/816-6408-10/handlers.htm#1120545>
> Now, how to know if the BODY load event has fired? Set a flag, of
> course.
That is what I was aiming at. But some people apparently need it to be
spelt to them, so thank you for that.
PointedEars
--
Anyone who slaps a 'this page is best viewed with Browser X' label on
a Web page appears to be yearning for the bad old days, before the Web,
when you had very little chance of reading a document written on another
computer, another word processor, or another network. -- Tim Berners-Lee
David Mark
wrote:
> David Mark wrote:
> > On Nov 19, 3:07 pm, Matt Kruse <m...@thekrusefamily.com> wrote:
> >> On Nov 19, 1:06 pm, Thomas 'PointedEars' Lahn <PointedE...@web.de>
> >> wrote:
> >> > <body onload="...">
>
> >> Script cannot add itself to this attribute, though.
>
> > Groan. Script doesn't have to "add itself" to this attribute.
>
> See below.
>
> >> You're steering away from the real question, anyway.
>
> > Yes.
>
> No. I was just closing at it at a slower pace :)
I figured. I'd just as soon be done with the discussion.
>
> >> Regardless of
> >> whether you feel it should be used, is there any cross-browser way to
> >> detect if window.onload has already fired?
>
> > Of course. Attach a load listener (or use the standard onload
> > attribute). They both do the same thing. One is proprietary and one
> > is not.
>
> But if we assume that, due to the flawed concept, there are only "lazy-
> loaded" scripts, there is a chicken-and-the-egg problem with adding a load
> listener with scripting. Hence my recommendation to use the `onload'
> attribute of the `body' element in the first place.
Right. The whole question is silly.
>
> > The proprietary window.onload property likely came about so that
> > scripts in the HEAD could set a load listener to the BODY before the
> > body is ready.
>
> Unlikely: <http://docs.sun.com/source/816-6408-10/handlers.htm#1120545>
I don't follow.
Jorge
wrote:
>
> Unlikely: <http://docs.sun.com/source/816-6408-10/handlers.htm#1120545>
If you specify an onLoad event handler for an Image object that
displays a looping GIF animation (multi-image GIF), each loop of the
animation triggers the onLoad event, and the event handler executes
once for each loop.
Is this true ?
--
Jorge.
David Mark
It was. Not a concern today as nobody (sane) uses animated GIF's on
the Web.
Jorge
Not even spinners ?
--
Jorge.
Thomas 'PointedEars' Lahn
> Thomas 'PointedEars' Lahn wrote:
>> David Mark wrote:
>> > The proprietary window.onload property likely came about so that
>> > scripts in the HEAD could set a load listener to the BODY before the
>> > body is ready.
>>
>> Unlikely: <http://docs.sun.com/source/816-6408-10/handlers.htm#1120545>
>
> I don't follow.
There is no mentioning of setting a listener to the BODY with window.onload
there.
Gregor Kofler
An onload listener for spinners which indicate loading processes? Sound
pretty recursive...
Gregor
Jorge
> Jorge meinte:
>
> > On Nov 20, 12:01 am, David Mark <dmark.cins...@gmail.com> wrote:
> >> It was. Not a concern today as nobody (sane) uses animated GIF's on
> >> the Web.
>
> > Not even spinners ?
>
> An onload listener for spinners which indicate loading processes? Sound
> pretty recursive...
LOL, yes. I've tested it and doesn't work in any (current) browser, as
Mark said.
--
Jorge.
David Mark
Certainly not paired with an onload listener. ;) And I think the
onload firing on-loop issue is only in ancient browsers.
Matt Kruse
> And what sort of scheme are they working on where their scripts are
> unclear about whether the load event has fired? Sounds like a recipe
> for disaster to me.
Apparently some people want to lazy-load scripts (libraries, etc) that
are not needed immediately for page rendering, so they don't block and
slow down the page load. As a way of getting the UI to the user faster
and then add script for when they interact.
I'm not a big fan of doing things onload of the page, especially not
attaching critical functionality. A common jQuery recommendation is to
wrap code in $(document).ready() so it fires when the DOM is ready, at
which point you can attach event handlers, etc. I always recommend
against this approach for a number of reasons, and I rarely (if ever)
use this approach.
Nevertheless, there are many plugins and 3rd-party components that use
this approach, and if you lazy-load jQuery after window.onload has
fired then these scripts will try to attach to the event and it will
never fire.
I thought it was an interesting question, as to whether or not the
condition could be checked in script.
> <body onload="loaded = true;">
And this is not possible by a lazy-loaded script, which was the point
of the original question. A script retrieved and eval'd via ajax will
obviously not be able to add code to a static html tag.
> Or, as mentioned, set window.onload if you think that is a cooler,
> more "unobtrusive" solution (despite the inherent drawbacks).
Solve the problem by turning a blind eye? :)
Matt Kruse
David Mark
> On Nov 19, 4:00 pm, David Mark <dmark.cins...@gmail.com> wrote:
>
> > And what sort of scheme are they working on where their scripts are
> > unclear about whether the load event has fired? Sounds like a recipe
> > for disaster to me.
>
> Apparently some people want to lazy-load scripts (libraries, etc) that
> are not needed immediately for page rendering, so they don't block and
> slow down the page load. As a way of getting the UI to the user faster
> and then add script for when they interact.
Some people use jQuery, which is a huge hit to start with. It's a
crazy world.
>
> I'm not a big fan of doing things onload of the page, especially not
> attaching critical functionality. A common jQuery recommendation is to
> wrap code in $(document).ready() so it fires when the DOM is ready, at
> which point you can attach event handlers, etc. I always recommend
> against this approach for a number of reasons, and I rarely (if ever)
> use this approach.
Seems sensible given they've been fretting that function for years and
it is known to be a bunch of hacks strung together by observation. I
read the recent exchanges and they are going down the same road to
"solve" this case.
>
> Nevertheless, there are many plugins and 3rd-party components that use
> this approach, and if you lazy-load jQuery after window.onload has
> fired then these scripts will try to attach to the event and it will
> never fire.
Load the entire _library_ after load? The idea is completely absurd.
But a flag still works. All jQuery has to do is check the flag and
act accordingly.
>
> I thought it was an interesting question, as to whether or not the
> condition could be checked in script.
>
> > <body onload="loaded = true;">
>
> And this is not possible by a lazy-loaded script, which was the point
> of the original question.
You just don't get it. The flag is for the lazy loaded script.
That's how it knows that the load event for the body has fired. You
could also use window.onload or attach a load listener to the body
(assuming your script is not in the head).
> A script retrieved and eval'd via ajax will
> obviously not be able to add code to a static html tag.
A script retrieved and eval'd via Ajax? There go all of your
perceived speed benefits. Doing that with a script like jQuery is
absurd.
And of course it could set that attribute, but that's not the point.
The point is that it won't do anything. Neither will window.onload,
which could also be set by the evaluated script. But if the evaluated
script checked a flag first or called a predetermined global function
to add "ready listeners". Last line of the loaded script would "fire"
all of them in turn if the flag is set (or call a function to do the
same thing).
>
> > Or, as mentioned, set window.onload if you think that is a cooler,
> > more "unobtrusive" solution (despite the inherent drawbacks).
>
> Solve the problem by turning a blind eye? :)
No.
Stevo
Shame there was no resolution to this. I was hoping for an answer to it
also. Instead of focusing on the question (the second paragraph above)
all the answers disregarded it.
I guess there is no way to find out if it's fired using regular DOM methods.
Matt Kruse
> Shame there was no resolution to this. I was hoping for an answer to it
> also. Instead of focusing on the question (the second paragraph above)
> all the answers disregarded it.
Typical of this group, which is why it's become mostly irrelevant.
> I guess there is no way to find out if it's fired using regular DOM methods.
It doesn't appear so.
Or to phrase it differently, a script that is executing after the
firing of window.onload has no independent way of determining that it
has already fired.
Matt Kruse
Andrew Poulos
> On Nov 23, 1:46 pm, Stevo <n...@mail.invalid> wrote:
>> Shame there was no resolution to this. I was hoping for an answer to it
>> also. Instead of focusing on the question (the second paragraph above)
>> all the answers disregarded it.
>
> Typical of this group, which is why it's become mostly irrelevant.
Maybe for you but not for me.
Andrew Poulos
RobG
> Matt Kruse wrote:
> > There is a discussion going on in the jquery-dev mailing list that
> > piqued my curiosity. I'm interested to know if the smart people here
> > have a good answer.
>
> > Is there a cross-browser way, in script, to determine if window.onload
> > has already fired?
>
> > If a script is lazy loaded and needs the DOM to be ready, it can
> > attach to the window's load event. But if that has already fired, then
> > the script's code will never run. Alternatively, it can just fire its
> > code inline, but the DOM may not be ready.
>
> > Thoughts?
>
> > Matt Kruse
>
> Shame there was no resolution to this.
There was a resolution.
> I was hoping for an answer to it
> also.
There was.
> Instead of focusing on the question (the second paragraph above)
> all the answers disregarded it.
There were two answers that focussed specifically on the question and
provided two approaches.
> I guess there is no way to find out if it's fired using regular DOM methods.
You got it, but that wasn't the question. There was no specific
mention of a DOM method, but that doesn't mean there aren't strategies
for determining if it's occurred.
--
Rob
David Mark
Matt Kruse wrote:
> On Nov 23, 1:46 pm, Stevo <n...@mail.invalid> wrote:
> > Shame there was no resolution to this. I was hoping for an answer to it
> > also. Instead of focusing on the question (the second paragraph above)
> > all the answers disregarded it.
>
> Typical of this group, which is why it's become mostly irrelevant.
Typical of your petulance and incompetence, you can't see the forest
for the trees. Clearly you came into this fact-finding mission with a
negative attitude (as usual).
>
> > I guess there is no way to find out if it's fired using regular DOM methods.
>
> It doesn't appear so.
Then you are blind. There must be some script that downloads the
secondary code. So that script sets an onload listener that sets a
"loaded" flag. The other scripts refer to that flag. End of story.
>
> Or to phrase it differently, a script that is executing after the
> firing of window.onload has no independent way of determining that it
> has already fired.
No kidding. You should have put it that way to start with. ;)
Matt Kruse
> Then you are blind. There must be some script that downloads the
> secondary code. So that script sets an onload listener that sets a
> "loaded" flag. The other scripts refer to that flag. End of story.
1) That depends on the first script setting an onload listener. What
if it is loaded after window.onload?
2) This strategy assumes you can modify the source of the second
script.
Matt Kruse
Stevo
All it would take is for the browser to set window.onload = true after
it's called all registered onload handlers, and those of us who want to
know if it's already happened can check if(window.onload === true). I
wish one of them would take the lead.
The DOMContentLoaded event was a start in a related direction, but still
we have no simple properties that let script determine whether onload
has triggered, and/or whether the DOM is ready for full scripting.
To further explain what Matt and I are both looking for, here's an example.
Site A decides to load library script B at some point during the viewing
of a page. It's completely unknown when this might be. They might be
doing it in the head section, in the body section, or on-demand well
after the onload event has fired because of some user action.
Script B wants to know into which page state it's being loaded. Whether
or not the event has fired already.
Question: How can script B know if onload has fired without putting
demands on site A to have to set flags (because the browser itself
doesn't seem to want to).
David Mark
> On Nov 23, 8:15 pm, David Mark <dmark.cins...@gmail.com> wrote:
>
> > Then you are blind. There must be some script that downloads the
> > secondary code. So that script sets an onload listener that sets a
> > "loaded" flag. The other scripts refer to that flag. End of story.
>
> 1) That depends on the first script setting an onload listener. What
> if it is loaded after window.onload?
And, pray tell, what would have loaded it after onload? Whatever
script actually does the loading by XHR/eval must set the onload
listener. If you don't know how to set an onload listener before
load, you've got much bigger problems. ;)
>
> 2) This strategy assumes you can modify the source of the second
> script.
Again, no kidding. You think you are going to load any old script
after load and have it work like magic? How was it going to answer
your question (detecting onload having fired) if you didn't modify it
to do so?
David Mark
> Matt Kruse wrote:
> > On Nov 23, 8:15 pm, David Mark <dmark.cins...@gmail.com> wrote:
> >> Then you are blind. There must be some script that downloads the
> >> secondary code. So that script sets an onload listener that sets a
> >> "loaded" flag. The other scripts refer to that flag. End of story.
>
> > 1) That depends on the first script setting an onload listener. What
> > if it is loaded after window.onload?
>
> > 2) This strategy assumes you can modify the source of the second
> > script.
>
> > Matt Kruse
>
> All it would take is for the browser to set window.onload = true after
> it's called all registered onload handlers, and those of us who want to
> know if it's already happened can check if(window.onload === true). I
> wish one of them would take the lead.
>
> The DOMContentLoaded event was a start in a related direction, but still
> we have no simple properties that let script determine whether onload
> has triggered, and/or whether the DOM is ready for full scripting.
>
> To further explain what Matt and I are both looking for, here's an example.
>
> Site A decides to load library script B at some point during the viewing
And site A is running some script that can load scripts (call it
script X).
> of a page. It's completely unknown when this might be. They might be
> doing it in the head section, in the body section, or on-demand well
> after the onload event has fired because of some user action.
Doesn't matter as script X will set a global flag when onload fires.
>
> Script B wants to know into which page state it's being loaded. Whether
> or not the event has fired already.
Check the flag.
>
> Question: How can script B know if onload has fired without putting
> demands on site A to have to set flags (because the browser itself
> doesn't seem to want to).
Demands to set flags? If you are writing a script delivery mechanism,
setting a flag is not a big concern. And how would script B check
anything, browser set or otherwise (unless you modified it to do so?)
Stevo
Why can't you simply acknowledge that there are situations where asking
site A to change their page simply isn't an option? Then we have the
question that's being asked. Can script enquire whether the onload event
has fired. Not whether someone's set a flag.
There are sites that are run by multiple different departments in some
very large companies. They move slowly. They have processes in place and
development schedules. You don't just say "hey bill, set this flag for
me will you". It's much bigger than that, and you can wait 6 months to
get approval for any change. Other more localized parts of the site are
flexible and are running at a different pace. They might want to load
your script but have no power whatsoever when it comes to setting a flag
in the parent page.
If everyone could please just accept that the flag-setting option is not
always available, we can get back to the original question.
David Mark
I didn't say change site A any more than you are already changing it
by adding script X. Set the load listener in script X. Get it? If
they don't add this magic loader script to site A, you are SOL anyway,
right?
> Then we have the
> question that's being asked.
And answered. You (and Matt Kruse) are definitely missing something.
Bad company.
> Can script enquire whether the onload event
> has fired. Not whether someone's set a flag.
You've been told repeatedly that is not the case, but it doesn't
matter. You have to change site A (by adding your loader script) and
you would have to change any script that relied on it to check
property Z (non-existent) in the browser. So, instead of checking for
something you know is not there, check for the flag.
Stevo
David, I think you're viewing this from too simplistic a level. You're
assuming a simple site under the control of one person who has the power
to change any line of code anywhere at any time. In the real world that
just doesn't happen.
I hear what you're saying, I really do, but there's no way of setting a
load listener in the case I'm thinking of. There is no "script X" that's
being hand-written by somebody and "while they're at it, why don't they
set a load listener". We're talking about convoluted content management
systems that can be set to load an external library (Script B) but
there's no control over Site A or the code that's loading the library or
any access to onload listeners. If the CMS were to allow such
potentially site-breaking code then it would be remiss in it's duties.
Script B is assumed to be able to deal with all it's own requirements
and doesn't place any external demands on the site.
There are many examples of such cases where a site will one day decide
to load an external script file and then the next day they stop it. That
script file might do some user tracking, ask if the user wants to
complete a survey, put a short-term item onto the page. Any number of
things. One thing they share in common is that they're loaded up by a
simple script tag and expected to perform with no requirement or ability
to have the hosting page changed in any way to support it.
This is an issue I've wanted to know the answer to for a long time and
I'm just jumping on Matt's bandwagon to see if I can get the answer too.
David Mark
I think you are confused.
> You're
> assuming a simple site under the control of one person who has the power
> to change any line of code anywhere at any time. In the real world that
> just doesn't happen.
There it is. I am assuming no such thing.
>
> I hear what you're saying, I really do, but there's no way of setting a
> load listener in the case I'm thinking of.
What case is that? I'd really like to know how your loader script
will be unable to set a load listener.
> There is no "script X" that's
> being hand-written by somebody and "while they're at it, why don't they
> set a load listener".
Huh? Script X is the hypothetical script that you (and Matt Kruse)
are trying to design. It loads scripts, not with SCRIPT elements, but
with XHR and eval. Or perhaps it will inject a SCRIPT element.
Regardless, you will need a script to pull this off. ;)
> We're talking about convoluted content management
> systems that can be set to load an external library (Script B) but
> there's no control over Site A or the code that's loading the library or
> any access to onload listeners.
Is that what we are talking about? Never mind if it is convoluted or
a CMS. There are two possibilities:
1. SCRIPT element is included in the markup. No problem there.
2. Some script somewhere in your document(s) will have to be executed
to load Script B. That's the script that must set the load listener
which sets the flag so that Script B will know whether the document is
loaded.
> If the CMS were to allow such
> potentially site-breaking code then it would be remiss in it's duties.
What? The CMS would be responsible for generating or including the
loader "bootstrap" script (or just including the required external
scripts in the markup). You said the CMS would be "set to load an
external library." If the CMS is set to do that, it will have to do
it. ;)
> Script B is assumed to be able to deal with all it's own requirements
> and doesn't place any external demands on the site.
So, if I gave you a magic property to check to see if the document is
loaded, how is it that script B would check it (unless you modified it
or there was a prior agreement with the author).
>
> There are many examples of such cases where a site will one day decide
> to load an external script file and then the next day they stop it.
That's as easy as adding and then removing a SCRIPT element. Or if
you use a "convoluted CMS", perhaps it can do this for you.
> That
> script file might do some user tracking, ask if the user wants to
> complete a survey, put a short-term item onto the page. Any number of
> things.
So?
> One thing they share in common is that they're loaded up by a
> simple script tag and expected to perform with no requirement or ability
> to have the hosting page changed in any way to support it.
And?
>
> This is an issue I've wanted to know the answer to for a long time and
> I'm just jumping on Matt's bandwagon to see if I can get the answer too.
What issue?
Garrett Smith
> All it would take is for the browser to set window.onload = true after
> it's called all registered onload handlers, and those of us who want to
> know if it's already happened can check if(window.onload === true). I
> wish one of them would take the lead.
>
> The DOMContentLoaded event was a start in a related direction, but still
> we have no simple properties that let script determine whether onload
> has triggered, and/or whether the DOM is ready for full scripting.
>
Sounds like you want a state variable for the document.
document.readyState == "complete" ?
In Firefox 3.6[1].
Already in IE, Safari, and Opera.
> To further explain what Matt and I are both looking for, here's an example.
>
> Site A decides to load library script B at some point during the viewing
> of a page. It's completely unknown when this might be. They might be
> doing it in the head section, in the body section, or on-demand well
> after the onload event has fired because of some user action.
>
> Script B wants to know into which page state it's being loaded. Whether
> or not the event has fired already.
>
> Question: How can script B know if onload has fired without putting
> demands on site A to have to set flags (because the browser itself
> doesn't seem to want to).
The loader script can determine what the state of the document is in and
set the flag. What's wrong with that?
[1]https://developer.mozilla.org/en/DOM/document.readyState
--
Garrett
comp.lang.javascript FAQ: http://jibbering.com/faq/
David Mark
[snip]
> Typical of this group, which is why it's become mostly irrelevant.
>
Typical of you, you don't know your evidence. ISTM that you have
floated the posting traffic in the jQuery group(s) as an indicator of
relative relevance. I will assume you still subscribe to that theory,
at least up until you read the next couple of lines (then cognitive
dissonance will kick in and you will find a new belief).
Know what this is?
4206 4167 3792 3351 2655 2904 2895 2651 2500
2251 1866
The tallies for the last eleven months for the primary jQuery user
group. Last month here was 2169.
Of course, I am assuming that GG can count (probably +/-500 margin of
error). :)
David Mark
It isn't a cross-browser solution and that property is available to
the loaded script, so it doesn't need to be mirrored in a flag. The
loader script can set a load listener. The load listener sets a
flag. That's the only way to know for sure if the document is loaded.
>
> [1]https://developer.mozilla.org/en/DOM/document.readyState
https://developer.mozilla.org/en/DOM/window.onload
https://developer.mozilla.org/en/DOM/element.addEventListener
Stevo
Unbelievable. After 3 years they finally decided to implement
document.readyState. That is the ideal solution. It would be nice if
they built it into FF2 and FF3.0 and FF3.5 also.
Stevo
I don't have a loader script, that's how.
>> There is no "script X" that's
>> being hand-written by somebody and "while they're at it, why don't they
>> set a load listener".
>
> Huh? Script X is the hypothetical script that you (and Matt Kruse)
> are trying to design. It loads scripts, not with SCRIPT elements, but
> with XHR and eval. Or perhaps it will inject a SCRIPT element.
> Regardless, you will need a script to pull this off. ;)
No. Neither of us is designing a loader script.
We are working on "the loaded script" (the script that gets loaded by a
script loading mechanism out of our control).
When we load, we're loading into an unknown situation and we're trying
to assess what that situation is. Have we been loaded into a fully
complete page (in which case window.onload has fired already), or are we
being loaded before window.onload has been fired.
The script that does the loading is nothing to do with us at all. It
belongs to the site and doesn't set any flags.
You'll come across it one day, but until you do, it's nothing to worry
about.
David Mark
But Matt Kruse was asking about a hypothetical loader script that uses
XHR/eval to load scripts. Are you off his bandwagon now?
>
> >> There is no "script X" that's
> >> being hand-written by somebody and "while they're at it, why don't they
> >> set a load listener".
>
> > Huh? Script X is the hypothetical script that you (and Matt Kruse)
> > are trying to design. It loads scripts, not with SCRIPT elements, but
> > with XHR and eval. Or perhaps it will inject a SCRIPT element.
> > Regardless, you will need a script to pull this off. ;)
>
> No. Neither of us is designing a loader script.
>
> We are working on "the loaded script" (the script that gets loaded by a
> script loading mechanism out of our control).
Well, Matt said in an earlier "rebuttal":-
"2) This strategy assumes you can modify the source of the second
script."
So now I know you fell off the wagon. :)
>
> When we load, we're loading into an unknown situation and we're trying
> to assess what that situation is. Have we been loaded into a fully
> complete page (in which case window.onload has fired already), or are we
> being loaded before window.onload has been fired.
As mentioned. No good. And, as it sits, document.readyState can't
help you either (maybe in five years). So design accordingly if you
site is scheduled for launch prior to 2015. ;)
[snip]
>
> You'll come across it one day, but until you do, it's nothing to worry
> about.
I know "it" is nothing to worry about. You just can't worry about
fantasy scenarios.
Garrett Smith
> On Nov 24, 2:31 am, Garrett Smith <dhtmlkitc...@gmail.com> wrote:
>> Stevo wrote:
>>> Matt Kruse wrote:
>>>> On Nov 23, 8:15 pm, David Mark <dmark.cins...@gmail.com> wrote:
[snip]
>>
>> document.readyState == "complete" ?
>>
>> In Firefox 3.6[1].
>>
>> Already in IE, Safari, and Opera.
>>
>>> To further explain what Matt and I are both looking for, here's an example.
>>> Site A decides to load library script B at some point during the viewing
>>> of a page. It's completely unknown when this might be. They might be
>>> doing it in the head section, in the body section, or on-demand well
>>> after the onload event has fired because of some user action.
>>> Script B wants to know into which page state it's being loaded. Whether
>>> or not the event has fired already.
>>> Question: How can script B know if onload has fired without putting
>>> demands on site A to have to set flags (because the browser itself
>>> doesn't seem to want to).
>> The loader script can determine what the state of the document is in and
>> set the flag. What's wrong with that?
>
> It isn't a cross-browser solution and that property is available to
> the loaded script, so it doesn't need to be mirrored in a flag. The
> loader script can set a load listener. The load listener sets a
> flag. That's the only way to know for sure if the document is loaded.
>
I think we are discussing the exact same thing here.
I should have stated that document.readyState is not widely enough
implemented; it is not even implemented in official Firefox release yet.
Sounds like Matt wants to have a user-defined Loader object to load the
scripts. SOmething like:
Loader.loadScripts(srcArray, scriptLoaded);
?
1) loader script adds to window.onload "loaderWindowOnload" (that sets
loader.complete=true).
2) loader loads script(s).
3) when a script is loaded, that script checks the loader's complete flag.
4) if the complete flag is false, the loaded script may add a callback
to window.onload. Otherwise, it just calls whatever function it needed.
This solves the problem where loader.loadScripts loads 10 scripts, the
first five are loaded before window.onload fires, then the next five are
loaded after onload, but the last five want to know about onload.
If the loaded scripts are designed so that they listen for
window.onload, they will be waiting forever. This approach solves that.
The problem with the "loader sets a flag" approach is that the loaded
scripts are necessarily coupled to the loader. The loaded scripts should
be able to be run and tested without knowing about how they were loaded,
or some global "loader.complete" flag.
Loader could steal window.onload is refire it after all scripts have
loaded, however that can still fail easily, in many cases, such as:
loaded script listens for "load" using addEventListener or attachEvent,
loaded script checks document.readyState, loaded script uses
document.write.
If the loaded script is only allowed to check a flag, complications are
eliminated.
Its ;ate here; hope that makes good enough sense!
wilq
to extend MooTools idea of having DomReady to something that you ask
for. Cant tell you if this works, code looks quite hacky here.
(function(){
var domready = function(){
if (Browser.loaded) return;
Browser.loaded = true;
window.fireEvent('domready');
document.fireEvent('domready');
};
window.addEvent('load', domready);
if (Browser.Engine.trident){
var temp = document.createElement('div');
(function(){
($try(function(){
temp.doScroll(); // Technique by Diego Perini
return document.id(temp).inject(document.body).set('html',
'temp').dispose();
})) ? domready() : arguments.callee.delay(50);
})();
} else if (Browser.Engine.webkit && Browser.Engine.version < 525){
(function(){
(['loaded', 'complete'].contains(document.readyState)) ? domready
() : arguments.callee.delay(50);
})();
} else {
document.addEvent('DOMContentLoaded', domready);
}
})();
Evertjan.
> From what I know there is no simple way to check that.
check what?
[please always quote on usenet]
> Re: Can script determine if window.onload has already fired?
Sure, just start the onload function with
var onloading = true;
ans check that in your script.
--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)
kangax
> David Mark wrote:
>> On Nov 24, 1:57 am, Stevo <n...@mail.invalid> wrote:
>>> There is no "script X" that's
>>> being hand-written by somebody and "while they're at it, why don't they
>>> set a load listener".
>>
>> Huh? Script X is the hypothetical script that you (and Matt Kruse)
>> are trying to design. It loads scripts, not with SCRIPT elements, but
>> with XHR and eval. Or perhaps it will inject a SCRIPT element.
>> Regardless, you will need a script to pull this off. ;)
>
> No. Neither of us is designing a loader script.
>
> We are working on "the loaded script" (the script that gets loaded by a
> script loading mechanism out of our control).
>
> When we load, we're loading into an unknown situation and we're trying
> to assess what that situation is. Have we been loaded into a fully
> complete page (in which case window.onload has fired already), or are we
> being loaded before window.onload has been fired.
Why not check if whatever element you're trying to use is available?
Maybe do some kind of polling. Ultimately, aren't you trying to detect
document readiness?
[...]
--
kangax
Jorge
> wilq wrote on 24 nov 2009 in comp.lang.javascript:
>
> > From what I know there is no simple way to check that.
>
> check what?
>
> [please always quote on usenet]
>
> > Re: Can script determine if window.onload has already fired?
>
> Sure, just start the onload function with
>
> var onloading = true;
>
> ans check that in your script.
A local var ???
--
Jorge
Evertjan.
True
Declare it global first.
Matt Kruse
> On Nov 23, 11:12 pm, Matt Kruse <m...@thekrusefamily.com> wrote:
> > 1) That depends on the first script setting an onload listener. What
> > if it is loaded after window.onload?
> And, pray tell, what would have loaded it after onload?
For example, something like GreaseMonkey. Or any tool which injects
scripts. Or perhaps a bookmarklet. Use your imagination, there are a
number of cases where a script under your control is injected into a
document and you have no control over the source document or when/how
your code gets inserted.
The ajax/eval method was just an example.
Matt Kruse
Matt Kruse
> On Nov 23, 3:51 pm, Matt Kruse <m...@thekrusefamily.com> wrote:
> > Typical of this group, which is why it's become mostly irrelevant.
> Typical of you, you don't know your evidence. ISTM that you have
> floated the posting traffic in the jQuery group(s) as an indicator of
> relative relevance.
Indeed.
The lower signal/noise ration in here and the fewer posts is an
indicator as well.
> I will assume you still subscribe to that theory,
> at least up until you read the next couple of lines (then cognitive
> dissonance will kick in and you will find a new belief).
> Know what this is?
> 4206 4167 3792 3351 2655 2904 2895 2651 2500
> 2251 1866
> The tallies for the last eleven months for the primary jQuery user
> group. Last month here was 2169.
The jQuery group is being moved away from Groups because of
unmanageable spam. The number of readers may be reflected by this.
Or perhaps jQuery is becoming so well known and documented that not as
many people need help with it. How do you like them apples? :)
Or perhaps jQuery popularity is fading. If that's the case, so be it.
Perhaps it will be replaced by something different as the most popular
scripting library. Doesn't matter to me.
Matt Kruse
David Mark
> On Nov 24, 1:41 am, David Mark <dmark.cins...@gmail.com> wrote:
>
> > On Nov 23, 3:51 pm, Matt Kruse <m...@thekrusefamily.com> wrote:
> > > Typical of this group, which is why it's become mostly irrelevant.
> > Typical of you, you don't know your evidence. ISTM that you have
> > floated the posting traffic in the jQuery group(s) as an indicator of
> > relative relevance.
>
> Indeed.
>
> The lower signal/noise ration in here and the fewer posts is an
> indicator as well.
Yes, it is very noisy in the jQuery group as few seem to have a clue
what they are discussing. ;) How is that a plus?
>
> > I will assume you still subscribe to that theory,
> > at least up until you read the next couple of lines (then cognitive
> > dissonance will kick in and you will find a new belief).
> > Know what this is?
> > 4206 4167 3792 3351 2655 2904 2895 2651 2500
> > 2251 1866
> > The tallies for the last eleven months for the primary jQuery user
> > group. Last month here was 2169.
>
> The jQuery group is being moved away from Groups because of
> unmanageable spam. The number of readers may be reflected by this.
Yes, some of them may be spammers that got through rather than
readers. So you adjust the totals downward to compensate.
>
> Or perhaps jQuery is becoming so well known and documented that not as
> many people need help with it. How do you like them apples? :)
You know that's not true (at least if you have ever read the code).
Virtually every jQuery example in print or online uses the attr
method. How do you like that apple?
http://groups.google.com/group/comp.lang.javascript/browse_thread/thread/e106af2d970d9b29#
It's rotten.
>
> Or perhaps jQuery popularity is fading. If that's the case, so be it.
Yes, IE8's arrival coincides almost exactly with the nosedive trend.
Who could have seen that coming? :)
> Perhaps it will be replaced by something different as the most popular
> scripting library. Doesn't matter to me.
Obviously it will be "replaced". Science doesn't have any pity on
lazy, destructive code monkeys. And neither does business, but it
takes a while for ideas to percolate to that level.
David Mark
And, as mentioned, there is no magic property to determine if the
document has loaded. End of story for those examples.
>
> The ajax/eval method was just an example.
Yeah, that's the one you came up with, so that's the one I responded
to.
wilq
I think that this problem might be more complicated than you think ;)
Please consider all cases - together with lazy load :)
David Mark
Realize that lazy loading of scripts is often indicative of lazy
programmers trying to hide that they are using much too general (and
therefore bloated) scripts. Or it may be Ajax-itis (the compelling
need to cram every app into one document).
beegee
> Realize that lazy loading of scripts is often indicative of lazy
> programmers trying to hide that they are using much too general (and
> therefore bloated) scripts. Or it may be Ajax-itis (the compelling
> need to cram every app into one document).
I think this was a *lazy* reply. There is a compelling case to be
made to a web user experience that resembles a stand-alone
application. Users generally get nervous when they are directed off
the home page. Even web 2.0 experiences like Facebook (basically 2
pages) are confusing to many. Now, Ajax in it's current state may not
be the way to get to the one-page application but the trend is to get
there.
The YUI Loader component is an attempt (unsuccessful in my opinion) to
implement the component approach of application development. In the
end, the suggestion of testing a global variable is exactly what the
OP is going to have to do. Every single script he downloads is going
to have to know of this variable or function. That IS the current
state of browser script load notification. I don't believe saying
that the need for such an approach shows bad design is correct.
Bob
Thomas 'PointedEars' Lahn
> On Nov 25, 4:04 am, David Mark <dmark.cins...@gmail.com> wrote:
>> Realize that lazy loading of scripts is often indicative of lazy
>> programmers trying to hide that they are using much too general (and
>> therefore bloated) scripts. Or it may be Ajax-itis (the compelling
>> need to cram every app into one document).
>
> I think this was a *lazy* reply. There is a compelling case to be
> made to a web user experience that resembles a stand-alone
> application.
Really?
> Users generally get nervous when they are directed off the home page.
Is there a usability study (say, by Nielsen) to support your opinion?
> Even web 2.0 experiences like Facebook (basically 2 pages) are confusing
> to many.
And this does not make you think in the right direction?
> Now, Ajax in it's current state may not be the way to get to the one-page
> application but the trend is to get there.
And incompetence like this makes the Web even more of an accessibility
nightmare, in a medium that should be open to as many people as possible.
> The YUI Loader component is an attempt (unsuccessful in my opinion) to
> implement the component approach of application development.
Yes, it is still much too bloated.
> In the end, the suggestion of testing a global variable is exactly what
> the OP is going to have to do.
Or the property of an object referred to by a global variable.
> Every single script he downloads is going to have to know of this variable
> or function. That IS the current state of browser script load
> notification. I don't believe saying that the need for such an approach
> shows bad design is correct.
There is no need if you use the modular approach properly. It's been done.
PointedEars
--
var bugRiddenCrashPronePieceOfJunk = (
navigator.userAgent.indexOf('MSIE 5') != -1
&& navigator.userAgent.indexOf('Mac') != -1
) // Plone, register_function.js:16
David Mark
> On Nov 25, 4:04 am, David Mark <dmark.cins...@gmail.com> wrote:
>
> > Realize that lazy loading of scripts is often indicative of lazy
> > programmers trying to hide that they are using much too general (and
> > therefore bloated) scripts. Or it may be Ajax-itis (the compelling
> > need to cram every app into one document).
>
> I think this was a *lazy* reply. There is a compelling case to be
> made to a web user experience that resembles a stand-alone
> application.
I know. I've been writing such applications since IE4. The key word
is "resembles" though. The user doesn't know or care how how much
navigation is involved (unless the design is so bad or the
implementation so bloated as to make navigation a problem).
> Users generally get nervous when they are directed off
> the home page.
I have no idea what that means. What home page? The average user
won't even notice moving from one page to the other if the two pages
are similar.
> Even web 2.0 experiences like Facebook (basically 2
> pages) are confusing to many.
Don't know what that means either. Users are more used to navigating
from one document to the next than to single-page docs that try to
work like apps (sporadically failing, which they do notice).
> Now, Ajax in it's current state may not
> be the way to get to the one-page application but the trend is to get
> there.
What trend? I've seen a lot of blithering about single page apps out
there, but no explanation as to why Web developers think that is a
general goal.
>
> The YUI Loader component is an attempt (unsuccessful in my opinion) to
> implement the component approach of application development.
It's an attempt to fill a perceived need.
> In the
> end, the suggestion of testing a global variable is exactly what the
> OP is going to have to do.
Right.
> Every single script he downloads is going
> to have to know of this variable or function.
Depends on what those scripts have to do. Context is king with this
stuff. Making broad generalizations usually leads to failure.
> That IS the current
> state of browser script load notification. I don't believe saying
> that the need for such an approach shows bad design is correct.
I don't follow. Show me a single-page "app" that is too slow to load
(ostensibly requiring a hare-brain scheme to make it usable) and I'll
show you a more appropriate multi-page design that isn't. Lately it's
becoming a career. ;)
Garrett Smith
> There is a discussion going on in the jquery-dev mailing list that
> piqued my curiosity. I'm interested to know if the smart people here
> have a good answer.
>
> Is there a cross-browser way, in script, to determine if window.onload
> has already fired?
>
> If a script is lazy loaded and needs the DOM to be ready, it can
> attach to the window's load event. But if that has already fired, then
> the script's code will never run. Alternatively, it can just fire its
> code inline, but the DOM may not be ready.
>
> Thoughts?
>
A follow-up to my previous message in this thread.
Solution:
The loaded script must not listen to any window load or readystatechange
events and must not call document.write (no jQuery.ready).
A Loader adds a load callback to a script element, then appends that
script, triggering the browser to load the script. When the script's
onload fires, the callback calls callback function.
Decoupling the loaded scripts from the loader avoids the tight coupling
and allows flexibility in loading. The module may provide an init()
method, so that the module can be re-inited if/when document innerHTML
changes.
In contrast, if the callbacks get attached in a hidden-in-module-scope
onload, they fire only on load. This is a problem when innerHTML
changes, and in your case where the onload may have already fired.
A dynamically loaded script must be designed in a way that it can be
loaded at any time without problems. It must not call document.write,
and must not listen for any load or readystatechange events.
Does this make sense?
Jorge
> (...)
> A Loader adds a load callback to a script element, then appends that
> script, triggering the browser to load the script. When the script's
> onload fires, the callback calls callback function.
>
IIRC, I've seen a couple of strange things happen when doing so. In
some browser(s) the onload may not even fire for <script>s. And in
some browsers I've seen both the <script>'s source being parsed/run
synchronously and the onload event being handled synchronously too
(when the <script> was cached and got fetched immediatly, on-the fly,
from the cache). Is it me, is it too much coke, or has somebody else
seen any of these too ?
--
Jorge.
David Mark
> Matt Kruse wrote:
> > There is a discussion going on in the jquery-dev mailing list that
> > piqued my curiosity. I'm interested to know if the smart people here
> > have a good answer.
>
> > Is there a cross-browser way, in script, to determine if window.onload
> > has already fired?
>
> > If a script is lazy loaded and needs the DOM to be ready, it can
> > attach to the window's load event. But if that has already fired, then
> > the script's code will never run. Alternatively, it can just fire its
> > code inline, but the DOM may not be ready.
>
> > Thoughts?
>
> A follow-up to my previous message in this thread.
>
> Solution:
> The loaded script must not listen to any window load or readystatechange
> events and must not call document.write (no jQuery.ready).
>
> A Loader adds a load callback to a script element, then appends that
> script, triggering the browser to load the script. When the script's
> onload fires, the callback calls callback function.
I know you don't mean the load event of the SCRIPT element. That's
something to avoid, even in fantasy designs. ;)
"Jorge" actually got one right. I can't believe I'm saying this, but
have a look at his response.
Garrett Smith
OK, you've got me. All the food got me a little euphoric yesterday. I
Wrote "Solution" when I should have written: "Untested solution".
Regarding the timing problems you mention with onload, I've not seen those.
Then again, I've not testing dynamic script injection much. For
requesting remote data, I have always used XHR or iframe. Those work
fine when used sparingly with small amounts of data.
Using dynamic script injection, the loader would listen for script's
onreadystatechange and check the readyState:
function loaderWrappedCallback() {
var readyState = script.readyState;
// TODO: Timeout events.
if(!readyState || "complete" === readyState) {
callback();
}
// TODO: Error handler.
}
}
Further testing is warranted before such experimental technique can be a
recommended solution.
David Mark
That's not a cross-browser solution either.
>
> Further testing is warranted before such experimental technique can be a
> recommended solution.
Solution for what? Knowing exactly when any random script has
finished loading? That's a fantasy aspiration. And I've seen people
trying to do similar things in projects where they actually have
control over the loaded scripts (or define the standards for them).
The only sane solution is to call the callback from the loaded
script. I know that doesn't fit the proposed fantasy design, but I
think it bears repeating at this point.
Richard Maher
> Solution for what?
I am also not sure what problem the proposed solution solves. I thought the
OP wanted to delay till onload fired unless onload has fired in which case
run now.
> Knowing exactly when any random script has
> finished loading? That's a fantasy aspiration.
Based on available evidence I have to disagree. Depending of course on what
exactly you mean by "exactly" :-)
As well as the cross-browser issues I'd include that ONERROR as well or you
might find your CALLBACK being a tad unreliable, but then you didn't like
"onerror" either.
BTW. Is the thrust of the requirements spec for this question the fact that
various "libraries" have become so bloated and convoluted that they can no
longer be feasibly loaded at "onload" time? So when some one says, for
example, "jQuery's footprint is 120KB" then that's just the bootstarp code
and oodles more will be lazily-loaded?
Cheers Richard Maher
"David Mark" <dmark....@gmail.com> wrote in message
news:69d8195b-0814-4342...@p35g2000yqh.googlegroups.com...
Richard Maher
"beegee" <bgu...@gmail.com> wrote in message
news:7aceba43-77db-438f...@j24g2000yqa.googlegroups.com...
> On Nov 25, 4:04 am, David Mark <dmark.cins...@gmail.com> wrote:
>
> > Realize that lazy loading of scripts is often indicative of lazy
> > programmers trying to hide that they are using much too general (and
> > therefore bloated) scripts. Or it may be Ajax-itis (the compelling
> > need to cram every app into one document).
>
> I think this was a *lazy* reply. There is a compelling case to be
> made to a web user experience that resembles a stand-alone
> application. Users generally get nervous when they are directed off
> the home page. Even web 2.0 experiences like Facebook (basically 2
> pages) are confusing to many. Now, Ajax in it's current state may not
> be the way to get to the one-page application but the trend is to get
> there.
>
Seeing as some in this thread are seeking to draw the battle lines
between: -
a) Single-Page applications
and
b) a love afair with back-button optimation and browser history
let me add my 2cents and introduce a 3rd option: -
c) Multi-Tab, Single-Browser-Instance applications with JAVA Applets,
singletons and static class variables providing the inter-tab communication
and application-global memory.
Regardless of the concerted attempts of Microsoft and Google, and the not
insignificant prejudices of many here, I can't help seeing such a
feature-rich development and deployment environment growing exponentially!
(Especially since 6.10 and multipe-threads and cross-domain policy files,
(although I'd give JNLP deployment a big miss!))
>
> Bob
Cheers Richard Maher
PS. Now if we only had a reliable mechanism come API for guaranteeing a
page would be opened in a new tab in the same browser instance then that
would really help me out a lot! Is it there and I just can't find it? With
the amount of absolute bollocks to emerge from HTML5 surely something as
useful as TAB-management syntax could have got a guernsey?
PPS. And how the hell could they outlaw Frames???
PPPS. Don't forget to stick that ONUNLOAD event in every page you can! Let's
consign that back-button optimization to history :-)
David Mark
wrote:
> Hi Bob,
>
> "beegee" <bgul...@gmail.com> wrote in message
>
> news:7aceba43-77db-438f...@j24g2000yqa.googlegroups.com...
>
> > On Nov 25, 4:04 am, David Mark <dmark.cins...@gmail.com> wrote:
>
> > > Realize that lazy loading of scripts is often indicative of lazy
> > > programmers trying to hide that they are using much too general (and
> > > therefore bloated) scripts. Or it may be Ajax-itis (the compelling
> > > need to cram every app into one document).
>
> > I think this was a *lazy* reply. There is a compelling case to be
> > made to a web user experience that resembles a stand-alone
> > application. Users generally get nervous when they are directed off
> > the home page. Even web 2.0 experiences like Facebook (basically 2
> > pages) are confusing to many. Now, Ajax in it's current state may not
> > be the way to get to the one-page application but the trend is to get
> > there.
>
> Seeing as some in this thread are seeking to draw the battle lines
> between: -
> a) Single-Page applications
> and
> b) a love afair with back-button optimation and browser history
>
Nobody is drawing those lines (and if I understand you, they are not
mutually exclusive either). Context is what matters. Some apps make
sense as a single document and there is no reason for any app to foul
up navigation. I see GG recently figured out the latter point.
Jorge
> (...) Some apps make
> sense as a single document and there is no reason for any app to foul
For single page apps, in an attempt to link app's state <->
location.hash, I've found at least one reason: that hash changes don't
necessarily trigger an event.
--
Jorge.
Richard Maher
> there is no reason for any app to foul
> up navigation
And no navigation will be "fouled", just de-emphasised and de-optimized.
> that hash changes don't
> necessarily trigger an event.
Reason ii) It really trashes the normal lifecycle of Applets
So to all xenophobic, nervous-Nellies, clinging to the perceived security of
yesteryear, I say "Burn your bridges, your boats and anything else that
detracts from the now!" or maybe "This is the web-page; there are no other
pages!" :-)
Cheers Richard Maher
"Jorge" <jo...@jorgechamorro.com> wrote in message
news:595004d7-7f3b-4a05...@u7g2000yqm.googlegroups.com...
David Mark
Who told you to do that? I know it is popular to try to make single
pages look like multiple by screwing around with the hash, which must
confuse the users who are used to single page apps. :)
In any event, it's a bad design and there's no reason to do it at all
(except in the heads of some Web developers).
David Mark
wrote:
> Hi Jorge,
Please address the group.
>
> > there is no reason for any app to foul
> > up navigation
>
> And no navigation will be "fouled", just de-emphasised and de-optimized.
I wasn't saying there was. I was referring to one side of your drawn
lines, not your Java idea.
>
> > that hash changes don't
> > necessarily trigger an event.
>
> Reason ii) It really trashes the normal lifecycle of Applets
Java or no, it's a bad thing to do. We've been over that endlessly.
>
> So to all xenophobic, nervous-Nellies, clinging to the perceived security of
> yesteryear, I say "Burn your bridges, your boats and anything else that
> detracts from the now!" or maybe "This is the web-page; there are no other
> pages!" :-)
>
Is Jorge catching? :)
David Mark
wrote:
> Hi David,
>
> > Solution for what?
>
> I am also not sure what problem the proposed solution solves. I thought the
> OP wanted to delay till onload fired unless onload has fired in which case
> run now.
>
> > Knowing exactly when any random script has
> > finished loading? That's a fantasy aspiration.
>
> Based on available evidence I have to disagree. Depending of course on what
> exactly you mean by "exactly" :-)
What evidence is that?
>
> As well as the cross-browser issues I'd include that ONERROR as well or you
> might find your CALLBACK being a tad unreliable, but then you didn't like
> "onerror" either.
If a script is a 404 or has a syntax error or whatever, the document
that included it better be equipped to do without it. And it
shouldn't need any sort of callback to tell it a script failed to
load.
>
> BTW. Is the thrust of the requirements spec for this question the fact that
> various "libraries" have become so bloated and convoluted that they can no
> longer be feasibly loaded at "onload" time? So when some one says, for
> example, "jQuery's footprint is 120KB" then that's just the bootstarp code
> and oodles more will be lazily-loaded?
God only knows what jQuery developers are thinking. The base script
is too large and slow for mobile use (and full of extraneous garbage
that nobody needs). It makes life "simpler" by adding tons of
complexity and apps smaller by adding lots of unneeded script. Lazy
loading on top of it would be slower than including the scripts
normally. And they don't know how to do feature testing yet anyway,
so how would they decide what to lazy load. ;)
Richard Maher
> What evidence is that?
Anecdotal++ With all browsers tested to date (Chrome, FF, and Safari) the
onload or onerror combo fires every time. With IE 7,8 the readystate value
may be a source of contention but the event(s) fire every time. Do you have
any evidence to the contrary?
Our cases deal only with <script> injection and specifically with JSON
Callbacks. We are accessing and Application (Service-Now) in our Software
Providers "cloud" and as the network/application response to The States can
be woeful we desperately needed local (but cross-domain) data and
business-rule access/validation. We also have an SSO product that can
substitute a login page for our scripts when the session times-out.
I submit to you (sorry "The Group" :-) that we have no silent failures and
we can verify the completeness of the load of our scripts. So you maintain
that I am living in cloud cuckoo land?
Cheers Richard Maher
Jorge
> On Nov 28, 3:20 am, "Richard Maher" <maher...@hotspamnotmail.com>
> > So to all xenophobic, nervous-Nellies, clinging to the perceived security of
> > yesteryear, I say "Burn your bridges, your boats and anything else that
> > detracts from the now!" or maybe "This is the web-page; there are no other
> > pages!" :-)
>
> Is Jorge catching? :)
I'm not sure. Ideally the app's state should be reflected in the url,
because a single-page web-app is single-page from the point of view of
the browser, but inside the app there might be many different views.
It's not easy to do it nowadays because touching the search part of
the url would trigger a reload, and touching the hash part may pass
unnoticed to the app (people are using timers to track it). M$ IIRC
has already implemented onHashChange in IE8, and others are following
(or is it the other way around ?). That will be of great help... in
the future :-(
Or, are you saying that there should be no link between the url and
the app's state ?
--
Jorge.
Jorge
wrote:
> (...)
> Anecdotal++ With all browsers tested to date (Chrome, FF, and Safari) the
> onload or onerror combo fires every time. With IE 7,8 the readystate value
> may be a source of contention but the event(s) fire every time. Do you have
So, the injected <script> either arrives or not, if it does you get
onload and if it doesn't you get onerror ?
Because, the onerror handler catches only http errors, right ?
--
Jorge.
Richard Maher
> So, the injected <script> either arrives or not, if it does you get
> onload and if it doesn't you get onerror ?
Yes (but IE is readystatechaneg)
> Because, the onerror handler catches only http errors, right ?
Yes. The callback must use whatever protocol/flag you like to indicate it
fired. The oneload,onerror,onreadstatechange tells the loading script when
it's safe to to check the flag. If Site-Minder has got in the way the onload
fires but no flag has been set.
--
> Jorge.
Cheers Richard Maher
David Mark
wrote:
> "David Mark" <dmark.cins...@gmail.com> wrote in message
>
> news:f3503614-48a8-4873...@m3g2000yqf.googlegroups.com...
>
> > What evidence is that?
>
> Anecdotal++ With all browsers tested to date (Chrome, FF, and Safari) the
> onload or onerror combo fires every time. With IE 7,8 the readystate value
> may be a source of contention but the event(s) fire every time. Do you have
> any evidence to the contrary?
Your hypothesis is what? All you've done is to test some version of
three browsers (and two of them are virtually identical). If you are
on a search for a failure, you are taking the long way around. Think
about what _not_ finding a failure in 3, 30 or 300 browsers means.
You have to have some basis for your interpretation of the evidence.
Usually that starts with specs and history going back further than the
browsers in front of you. Anecdotal evidence is not a starting
point. Conclusions drawn strictly from observation are pretty much
baseless in browser scripting.
>
> Our cases deal only with <script> injection and specifically with JSON
> Callbacks. We are accessing and Application (Service-Now) in our Software
> Providers "cloud" and as the network/application response to The States can
> be woeful we desperately needed local (but cross-domain) data and
> business-rule access/validation. We also have an SSO product that can
> substitute a login page for our scripts when the session times-out.
Okay.
>
> I submit to you (sorry "The Group" :-) that we have no silent failures and
> we can verify the completeness of the load of our scripts.
See above. What happens when you discover a browser that fails
silently? And why should you design your app(s) to rely on such
things if even their present viability is uncertain?
> So you maintain
> that I am living in cloud cuckoo land?
>
I don't recall saying that. :)
David Mark
David Mark
> On Nov 28, 10:08 am, David Mark <dmark.cins...@gmail.com> wrote:
>
> > On Nov 28, 3:20 am, "Richard Maher" <maher...@hotspamnotmail.com>
> > (...)
> > > So to all xenophobic, nervous-Nellies, clinging to the perceived security of
> > > yesteryear, I say "Burn your bridges, your boats and anything else that
> > > detracts from the now!" or maybe "This is the web-page; there are no other
> > > pages!" :-)
>
> > Is Jorge catching? :)
>
> I'm not sure.
> Ideally the app's state should be reflected in the url,
> because a single-page web-app is single-page from the point of view of
> the browser, but inside the app there might be many different views.
That makes zero sense (and I know about the views). ;)
> It's not easy to do it nowadays because touching the search part of
> the url would trigger a reload, and touching the hash part may pass
> unnoticed to the app (people are using timers to track it).
Web developers do all sorts of ill-advised things. :)
> M$ IIRC
> has already implemented onHashChange in IE8, and others are following
> (or is it the other way around ?).
As do browser developers.
> That will be of great help... in
> the future :-(
No it won't.
>
> Or, are you saying that there should be no link between the url and
> the app's state ?
Search the archive, Jorge. We've been over this a million times.
Jorge
>
> Search the archive, Jorge. We've been over this a million times.
IIRC, last time I saw a thread about this Peter Michaux said ~ what
I'm saying now, and you instead thought that state should be saved in
cookies, not-at-all in the url#hash, right ?
ISTM that cookies (and/or client-side persistent storage, when/if
available) are there -of course- to save state. But, it also STM that
that's not all that there's to it, because neither cookies nor client-
side persistent storage can be passed along in a url, and that's part
of the story. Say your app does bells and whistles, how would you -
with cookies- pass someone else a link to the bells panel ?
So I don't get why using #hash to save -some- state is ill-advidsed
(?). Just because the (missing) events ?
--
Jorge.
beegee
wrote:
> beegee wrote:
> > I think this was a *lazy* reply. There is a compelling case to be
> > made to a web user experience that resembles a stand-alone
> > application.
>
> Really?
Yes. Well actually it was supposed to be "case to be made *for* a web
experience..."
> > Users generally get nervous when they are directed off the home page.
>
> Is there a usability study (say, by Nielsen) to support your opinion?
I over-generalized. Anecdotally, users I have come into contact
with...etc.
>
> > Even web 2.0 experiences like Facebook (basically 2 pages) are confusing
> > to many.
>
> And this does not make you think in the right direction?
As I implied, it makes me think that 2 pages are one too many.
> > Now, Ajax in it's current state may not be the way to get to the one-page
> > application but the trend is to get there.
>
> And incompetence like this makes the Web even more of an accessibility
> nightmare, in a medium that should be open to as many people as possible.
I don't really see any incompetence. What the OP wants to do sounds
quite reasonable to me.
Perhaps I'm mistaken and the realm of the *connected* application is
to be claimed by Air or Silverlight. That means, though, that what we
do; program javascript in client browsers will be relegated to adding
fancy geegaws and doodads to static web pages. NOT what I want to
do. I must admit though, that I don't worry much about
accessibility. With all the different browsers and thirty-party add-
ons, I see getting anywhere near transparent accessibility as a pipe-
dream. Javascript turned off? Too bad, buddy, you get a big fat
white page with the words "Come back when you get over it." No, not
really but a man can dream, can't he?
>
> There is no need if you use the modular approach properly. It's been done.
Mostly, again, what I've seen of the modular approach is the 10 pages
with the same decoration or worse, server-side generation of HTML. I
have not seen all patters of serving up web pages though so if you
have something else in mind, please enlighten. In fact, I think a
discussion of different "web patterns" would be really useful, like
MVC Server, MVC Client, Mixed html and server-side, client-side js
called web services. I'm sure there's a pattern for on-demand
javascript.
Bob
Garrett Smith
> On Nov 27, 2:19 pm, Garrett Smith <dhtmlkitc...@gmail.com> wrote:
>> Jorge wrote:
>>> On Nov 27, 7:56 am, Garrett Smith <dhtmlkitc...@gmail.com> wrote:
>>>> (...)
>
> The only sane solution is to call the callback from the loaded
> script.
jQuery already has that (though slightly more elaborate). The script
calls jQuery.ready. If the jQuery.isReady flag is true, then the
callback fires immediately. Otherwise, the callback is added to an Array.
if ( jQuery.isReady ) {
// Execute the function immediately
fn.call( document, jQuery );
} else {
// Otherwise, remember the function for later
// Add the function to the wait list
jQuery.readyList.push( fn );
}
A call to jQuery.ready after the had fired would call that function.
David Mark
You feel every page should have a different decor? Perhaps you are
subscribing to the belief that the background image, scripts, etc.
will be downloaded every time the user navigates? That's not true.
And what is wrong with "server side generation of HTML"? That is
where most HTML is generated. It sounds to me like you've been brain-
washed by over-generalization. :)
> I
> have not seen all patters of serving up web pages though so if you
> have something else in mind, please enlighten.
Something else in mind for what?
> In fact, I think a
> discussion of different "web patterns" would be really useful, like
> MVC Server, MVC Client, Mixed html and server-side, client-side js
> called web services.
No, client-side JS is not called Web services. I have seen attempts
to replace needed server side processing with pure client side script
in the name of using "Web services". That's how to turn something
simple that works for everyone on the planet into a dicey crap shoot
that works for some and does unexpected things for others. Somehow,
this is seen as a "cool" and progressive thing to do. But results
that developers don't expect won't lead to good experiences for users,
QA, support, etc. That's not cool at all (simply incompetent). ;)
> I'm sure there's a pattern for on-demand
> javascript.
I don't believe there's an atom of meaning in it.
Richard Maher
"beegee" <bgu...@gmail.com> wrote in message
news:abb20176-72dc-4f38...@l13g2000yqb.googlegroups.com...
> On Nov 26, 6:57 pm, Thomas 'PointedEars' Lahn <PointedE...@web.de>
> wrote:
..
> Perhaps I'm mistaken and the realm of the *connected* application is
> to be claimed by Air or Silverlight. That means, though, that what we
> do; program javascript in client browsers will be relegated to adding
> fancy geegaws and doodads to static web pages.
Once again there is the middle option. Flex, Silverlight, and JAVA *all*
open up their objects and methods to Javascript interaction. Adobe's
FABridge, Silverlight's HTML Bridge, and JAVA's just always done it +/-
LiveConnect. How much, or little, web-page real estate they occupy is up to
you. (I've personally used a faceless JAVA applet to retrieve employee data
from a socket and populate Flex ArrayCollections that became the data source
for Pie Charts and Data Grids. All happily co-existing on the same page with
bog-standard HTML fields and markup.)
The only people trying to lock you into an anti-plugin, anti-functionality,
anti-choice view of the world is that group of wheel re-inventors over at
HTML5. (Sadly, I expected something more than their square-shaped offerings
such as WebSockets)
..
> Bob
Cheers Richard Maher
beegee
> On Nov 29, 8:47 pm, beegee <bgul...@gmail.com> wrote:
>
> > Mostly, again, what I've seen of the modular approach is the 10 pages
> > with the same decoration or worse, server-side generation of HTML.
>
> You feel every page should have a different decor? Perhaps you are
> subscribing to the belief that the background image, scripts, etc.
> will be downloaded every time the user navigates? That's not true.
No, my point was that the web site is better served by having one page
that dynamically generates different display depending on downloaded
(via AJAX) content. In this way you can keep the same decord without
resorting to the braindead scheme of using ten different pages just
because your content changes.
> And what is wrong with "server side generation of HTML"? That is
> where most HTML is generated.
It shouldn't be, in my opinion. It is far easier to use server-side
generated *data* to generate html, client-side.
> > In fact, I think a
> > discussion of different "web patterns" would be really useful, like
> > MVC Server, MVC Client, Mixed html and server-side, client-side js
> > called web services.
>
> No, client-side JS is not called Web services. I have seen attempts
> to replace needed server side processing with pure client side script
> in the name of using "Web services". That's how to turn something
> simple that works for everyone on the planet into a dicey crap shoot
> that works for some and does unexpected things for others. Somehow,
> this is seen as a "cool" and progressive thing to do. But results
> that developers don't expect won't lead to good experiences for users,
> QA, support, etc. That's not cool at all (simply incompetent). ;)
Sorry, late at night for me. I meant "client-side js calling web
services." But no, now you're over-generalizing. Using web services to
retrieve data in order to generate UI elements and content is a very
nice way to separate business logic and UI.
>> I'm sure there's a pattern for on-demand
>> javascript.
> I don't believe there's an atom of meaning in it.
Ok, you're being a little fuddy-duddy here. I hope in taking up the
anti-jQuery banner, I haven't sided with a bunch of arch-conservative
javascript programmers ;)
Bob
beegee
wrote:
> Hi Bob,
>
> "beegee" <bgul...@gmail.com> wrote in message
>
> news:abb20176-72dc-4f38...@l13g2000yqb.googlegroups.com...
> Once again there is the middle option. Flex, Silverlight, and JAVA *all*
> open up their objects and methods to Javascript interaction. Adobe's
> FABridge, Silverlight's HTML Bridge, and JAVA's just always done it +/-
> LiveConnect. How much, or little, web-page real estate they occupy is up to
> you. (I've personally used a faceless JAVA applet to retrieve employee data
> from a socket and populate Flex ArrayCollections that became the data source
> for Pie Charts and Data Grids. All happily co-existing on the same page with
> bog-standard HTML fields and markup.)
>
Richard, I agree with you up to a point. I have used Silverlight
datagrids that get populated via XML->javascript->SL.
The silverlight control exists more-or-less happily with the DOM.
There is still quite a separation though, especially with graphics
coordinates. My experience with java applets was a complete nightmare
and I was in front of the line to dance on the coffin. Datagrids in
Flash and Silverlight have problems still both with UI and rendering.
If the browser did a little faster job of rendering large tables, I
would gladly dump Silverlight.
So, yup, I'll use the plugins to overcome shortcomings of the browser
but if HTML5 solves those shortcomings, I'm definitely dumping the
plugins.
Bob
David Mark
> David Mark wrote:
> > On Nov 27, 2:19 pm, Garrett Smith <dhtmlkitc...@gmail.com> wrote:
> >> Jorge wrote:
> >>> On Nov 27, 7:56 am, Garrett Smith <dhtmlkitc...@gmail.com> wrote:
> >>>> (...)
> [...]
>
> > The only sane solution is to call the callback from the loaded
> > script.
>
> jQuery already has that (though slightly more elaborate). The script
> calls jQuery.ready. If the jQuery.isReady flag is true, then the
> callback fires immediately. Otherwise, the callback is added to an Array.
But the isReady flag is dubious as it relies on jQuery's mixed up
DOMContentLoaded simulation. It's all fruit of a poisonous tree.