Can script determine if window.onload has already fired?
in [JavaScript]
|
From: Jorge on 28 Nov 2009 05:11 On Nov 28, 10:56 am, "Richard Maher" <maher...(a)hotspamnotmail.com> 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 > any evidence to the contrary? (...) 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.
From: Richard Maher on 28 Nov 2009 05:57 "Jorge" <jorge(a)jorgechamorro.com> wrote in message news:d9160c2c-7778-420d-856d-bc0a61d46676(a)j14g2000yqm.googlegroups.com... > 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
From: David Mark on 28 Nov 2009 06:14 On Nov 28, 4:56 am, "Richard Maher" <maher...(a)hotspamnotmail.com> wrote: > "David Mark" <dmark.cins...(a)gmail.com> wrote in message > > news:f3503614-48a8-4873-9141-9029a10bcce9(a)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. :)
From: David Mark on 28 Nov 2009 06:15 On Nov 28, 5:57 am, "Richard Maher" <maher...(a)hotspamnotmail.com> wrote: > "Jorge" <jo...(a)jorgechamorro.com> wrote in message > > news:d9160c2c-7778-420d-856d-bc0a61d46676(a)j14g2000yqm.googlegroups.com... > > > 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. Another observation. :)
From: beegee on 29 Nov 2009 20:47
On Nov 26, 6:57 pm, Thomas 'PointedEars' Lahn <PointedE...(a)web.de> 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 |