dean.edwards.name/weblog/2005/09/busted

Comment: #1

Copied!Thank you so much, Dean. I never would’ve even explored other options than the window.onload method if it wasn’t for guys like you!

Comment: #2

defer is part of HTML4

“defer [CI] When set, this boolean attribute provides a hint to the user agent that the script is not going to generate any document content (e.g., no “document.write” in javascript) and thus, the user agent can continue parsing and rendering”

Comment: #3

Erik – OK. I didn’t realise that. The real point is that only IE supports this attribute.

Comment: #4

This is good news, and I assume that neither methods will be disappearing from browsers anytime soon (they seem pretty well rooted)

I’m sure Opera must have a feature like the firefox one too, I know that is a completely unresearched statement, but considering the forward thinking standards based motivation of Opera and the fact it supports ‘user scripts’ and ‘browser scripts’ and plugins means that the must have allowed away for code to be executed after the dom loads. Mustn’t they?

Anyway, awesome work.

Comment: #5

Re: Erik Arvidsson

Part of HTML 4? hmm, maybe that means it will become unavailable if IE starts respecting doctypes better?

Comment: #6

About defer: interesting thing to note: it is #implied. See http://www.w3.org/TR/html401/interact/scripts.html#adef-defer.

On to your test. Is the following expected ? In Gecko browsers (tested firefox 1.5 beta and the latest nightly trunk build) the red and white message appears before the image has started loading. Other (Mac) browsers wait for the image to load fully before showing the message.

Comment: #7

Philippe – the test page works as expected. There is not much DOM content so the message should appear very quickly (almost instantly). That is pretty much the point of this exercise.

Comment: #9

Treating defer as equivalent to DOMContentLoaded seems pretty risky to me. DOMContentLoaded is a promise: the full DOM is available to you when it fires. defer is just your promise to the rendering engine, that the content of this script doesn’t depend on being loaded before following content, not their promise to load it at a particular time. Try trickling out your HTML with a PHP script that sends an element, then sleeps for a second or two, and based on my memory of playing with defer you’ll find your script loaded as soon as IE gets a chance, not after the DOM is fully loaded.

Comment: #10

Thanks, Dean. This is indescribable awesome if it works dependably. Of course, if it doesn’t doing the same (the IE piece) using an .htc isn’t the end of the world, but it seems there are more hoops to jump through to get that set-up right, so this is more elegant.

Comment: #11

Phil – I did as you suggested and it seems to still work. I’ve also used this technique on a page with multiple (50-60) behaviors attached and it waits for those to load too.

Comment: #12

Tim – you are right. You can also use an HTC and trap the ondocumentready event. As you point out, not everyone is able to deliver HTCs from their server.

Comment: #13

Dean: could you write up the HTC method too? The more options the better.

Comment: #15

there is another way… stick a call to your init function at the bottom of the page after your body tag. a lot simpler than tagsoup

Comment: #16

Right you are: I should test things, rather than rely on my increasingly horrible memory. I was actually using it for loading script from unreliable hosts, where I didn’t care if it came early or late, as long as it didn’t hang the page when it didn’t come at all. Trickling out a page says it works exactly like you say, delaying the load whether or not IE has time and connections to spare.

Comment: #17

taxexile – I’ve tested your technique in the past and it is not 100% reliable (more like 98%).

Comment: #18

Simon – I’ll document the HTC approach in a subsequent post – I didn’t want this post to be burdened with too many technicalities.

Comment: #19

The ‘defer’ attribute is a tricky little beast. Beware of dependencies between scripts when using the ‘defer’ attribute. i.e. if the ‘onload’ script in file2.js depends on functions defined in file1.js, you should avoid adding a ‘defer’ attribute to the script tag for file1.js.

The problems caused are infrequent, but are easily summarized by saying you cannot guarantee functions will be available from a deferred script until after ‘onload’ fires. Which is what you were using ‘defer’ for in the first place.

If everything’s in one big ‘defer’ script, you should be fine though.

And, what was the problem with using ‘onreadystatechange’ for Internet Explorer again?

Comment: #20

ash – you are probably right. It is safer to have only one deferred script.

As to your other point – the readyState property is unreliable. I’ve tested this extensively in the past and it only leads to disappointment.

Anyway, time for bed now – it’s 3.00am

Comment: #21

this *is* huge. I’ve been using a nasty CSS hack that applies “display: hidden” to the entire document and let an onload handler toggle it on to do some weird DOM stuff before the doc is displayed. Is the code in these event handlers guaranteed to run before the rendering phase?

Comment: #23

I filed a bug about this in Safari’s bug database.

Comment: #24

dean: if 2% of users were using Safari then we’d be at the same level (if your stat were even accurate!). this is just tag soup though isn’t? we’ll be using buffer-overflows in html next to trigger something next!! stick a script block at the bottom and let that do it. i think this ‘solution’ is ridiculous. love the htc-mozilla bridge though

Comment: #25

taxexile – I don’t think you understand the problem. Simply putting a script tag at the bottom of the page is not sufficient. Remember that the DOM needs to be loaded and parsed. PPK and others have explored your solution in the past and found it wanting.

Comment: #26

taxexile – I’m curious how, in any way shape or form, this is “tag soup” a very specific and completely unrelated problem (a script tag at the bottom of the page is closer to “tag soup” and has various shortcomings that have been addressed ad nauseam by many of us). This can help reduce tag soup, actually.

Do you mean hacky? If so I still disagree, as this is the most elegant soultion to a problem that has been bothering many of us for quite a while, but at least that makes sense.

Comment: #27

Simon – it might actually be a feature to NOT have Safari supported. I’ve read about some problems in scripts due to how Safari renders the page before images are loaded. I didn’t confirm it myself, but it sounded like it was something the sIFR people encountered (link in my blog).

Of course, even if it really is a problem, it’d be nice to have some way to do this in Safari if/when it ever gets resolved.

Comment: #28

Thanks, Dean

“DOMContentLoaded” is just the thing I really need!

BTW, you may try to use document.onreadyStateChange to call the function init() for internet explorer.

Comment: #29

> Well, when I say solved I mean solved for the two most important browsers – Internet Explorer and Mozilla/Firefox. Still that’s good enough isn’t it?

Nope, not quite good enoughBut here’s something I’ve been working on:

function onready(el, func){
	this.args = new Array(el, func)
	this.doTry = function(){
		try{
			var el = eval(this.args[0])
			el.onloading = this.args[1]
			el.onloading()
			clearInterval(this.args[2])

		}
		catch(e){}
	}
	this.doTry.bind = function(object){
		var method = this;
		return function(){
			method.apply(object);
		}
	}
	this.args[2] = setInterval(this.doTry.bind(this), 250);
	return this
}
new onready("document.body", function(){this.onclick=function(){alert("You good thing")}})

Comment: #30

Dear Dean,

I really appreciate your finding and had made an example on http://www.hedgerwow.com/360/dhtml/before_onload.php with some of your comments and codes.

Pleae let me know if you have any concern.

Thanks.

Comment: #33

I know I’m just being fussy here, but shouldn’t it be

defer="defer"

in XHTML?

Comment: #34

Nick – bearing in mind that we are using conditional comments/compilation I don’t think this is an issue.

Comment: #35

This windows.onload solution breaks the clearfix solution for ie: http://www.positioniseverything.net/easyclearing.html

Mmm, do not know why ..

Arjen

Comment: #36

ppk said:

The problem browser was Safari. I set the height of a few columns to the height of the highest among them onAlmostLoad, but Safari read the height as 0, which gave a very nasty effect.

No doubt this is solvable, if I’d have the time to do some research, but I assume that such small but fatal bugs will creep up as we use pseudo-onloads more and more.

I’m not saying it’s impossible to devise an onAlmostLoad event handler, but I do say it has to be researched very thoroughly. Besides, even when it works perfectly you still write JavaScript code in an XHTML file, which we shouldn’t do.

And the example he used was:

<script>
tweakPage()
</script>
</body>

I wonder if the same problem exists if that tweakPage() is put after the ending body tag:

</body>
<script>
tweakPage()
</script>

I don’t have a Mac, so I can’t test this out… But I’d like to have a solution that includes non-IE and non-Gecko browsers.

Comment: #37

I’ve had a different problem with onload — that of multiple, independent scripts all having their own separate initializations, each specifying “onload”. Since IE’s support of event-listener varies too much to be reliable, i’ve instead created an “initFunctions” array:; every function that needs to get initialized gets pushed onto that array, then the final onload simply iterates through the functions.

This issue has been far more critical as an onload handler problem than that of wanting to run scripts after the DOM is created but before images are loaded; we don’t have enough images in my app to worry about.

Comment: #38

For IE, what about using IE’s non-standard onReadyStateChange event? If you hook it up to “document” it will fire and document.readyState will equal “interactive” when the page can be accessed by script. I haven’t found anything that conclusively says this is the same thing as the DOM being loaded, but it behaves the same using your “busted.html” example.

Just add this to the code, it won’t effect browsers that don’t understand it:

/* for IE */
function statechange() {
	if (document.readyState == "interactive")
		init();
}

document.onreadystatechange = statechange;

Comment: #39

I’m going to say this one final time:

The readyState property is not a reliable way to determine if the document has been loaded and parsed.

Comment: #40

Oops sorry for the repeat. I worked with your test file some and see what you mean.

I notice you also mention that simply calling the init script at the bottom of the page is not 100% reliable either.

So I propose (and have successfully tested in Firefox, IE, and Opera) using a combination of methods. Add this to the bottom of the page (I haven’t found much difference between including it as the very last bit before the close body tag or between the close body and close html tags):

/* for IE */
function statechange() {
	if (document.readyState == "interactive")
		init();
}

if (document.readyState) {	
	if (document.readyState == "interactive" || document.readyState == "complete") {
		init();
	} else {
		document.onreadystatechange = statechange;
	}
}

Called at the end of the document, it will run init if readyState is either “interactive” or “complete”, or create the onreadystatechange event if it hasn’t reached either yet.

As a bonus, Opera recognizes the document.readyState variable even if it doesn’t recognize the onreadystatechange event, so Opera will also be able to init() before having to wait on images to load.

I’ve combined your ‘busted.html’ test with your ‘readyState.html’ content (and tripled the content for extra DOM padding) to stress-test this technique and have met with success. I wish I could test for Safari or Konqueror but I’m on Windows. You can run my test here.

Comment: #41

OK. Can people stop posting alternative solutions that involve either the readyState property, <script> tags at the end of the document or combinations thereof. These solutions are not reliable. I will delete any further postings along these lines so don’t waste your time.

Comment: #42

Without a solution for Safari this is interesting but still not quite practical IMO. I’m still falling back to a timer that watches for some conditions to become true (e.g document.getElementById(‘footer’).. We can shortcut that by including the event handlers for Gecko and IE – that’s good, but in the interest of less code forks and more simplicity, its easier to treat all browsers as the same. That said, I did come across an interesting problem using this approach. My original test was document.getElementsByTagName(“body”)[0].. reasoning that if the body node exist, my DOM is loaded and ready. Not so, so I’m back to checking for my footer (which makes this only useful where I can rely on knowing the id of the last element in the page.)

Does anyone know a better test that assures DOM readiness x-browser?

Comment: #43

Wouldn’t the cleaner solution be to add the following to your page:

<script defer="defer" src="onload_fix.js" type="text/javascript"></script>

And then have your onload_fix.js look like this:

// for IE
if( document.all ){
  init();
// for Mozilla browsers
} else if (document.addEventListener) {
  document.addEventListener("DOMContentLoaded", init, null);
// catch everything else
} else {
  window.init();
}

Granted, there’s potentially an issue where the DOM might be ready in Mozilla before it loads this script, but as small as the file is, I’m not sure it would be a huge issue.

Comment: #44

I’m using:

// Pre onload code execution.
function checkDOM(){
    if (getById("footer")||getById("credit")) Startup();
    else setTimeout("checkDOM();",100);
}

if (document.addEventListener) {
    document.addEventListener("DOMContentLoaded", Startup, null);
} else {
    setTimeout("checkDOM();",100);    
}

There is a bit of an artifact where the original DOM is displayed, then I make some edits. But it will do for now.

Comment: #45

dean, are you sure that deferring requires an external script? So far in my tests, an inline deferred script works just as well. The only difference is that the inline deferred script runs before the onpropertychanges, while the external deferred script runs after it, which means that if there was a “loading” readyState, it would still be “loading” on the inline defer, and “interactive” on the external one. I’m not sure if that means anything. Both can access the very last element in the document (just before the </html>) via id. Do you have a testcase in which the inline deferred script doesn’t work?

Comment: #46

So does this work?:

<script defer="defer">
 if( moz )
  document.addEventListener("DOMContentLoaded", init, null) :  
 else
  window.onload = init();
</script>

Comment: #47

Errr… I wish I could edit posts, delete them, and/or show code in them. Then I might be able to properly take part in the conversation without spending ten minutes trying to hack a snippet for HTML escape sequences.

Remove “window.onload =” in the above code. I typically use http headers and file extensions to specify mime-types; so I think it’s triple redundant redundant redundant to specify type and language. :p

Comment: #48

Still got a bunch of Problems with the ‘readyState’-Trigger.

Mozilla: Like mentioned before, Firefox does not know readyState. But somehow the Scipts don’t have to wait for anything. Although i still retrieve the designed parentobject via ‘getElement’ just to make sure, it’s already there.

Opera: Stays interaktiv while the images are loaded. ReadyState is no help breaking the boundary.

Internet-Explorer: Even with readyState equals complete you can get trouble if you want to append something to the body. The reason seems to be, that the body-tag still is not closed, inspite of readyState tells us something else.

Most of my problems seem to be caused in my attempt to append something to the body, while the body is the last thing in the DOM-Tree, which is complete. I rather should ask for the tag is closed, but still have not found a way to do so.

Comment: #49

Here’s the log of a modified version of dean’s test page:

document.onpropertychange (propertyName=onpropertychange (srcElement=null); last=null; body.offsetHeight=Object required)
document before body (readyState=loading; last=null; body.offsetHeight=Object required)
document body start (readyState=loading; last=null; body.offsetHeight=0)
styleSheet1 applied
styleSheet2 applied
document body half-way (readyState=loading; last=null; body.offsetHeight=12028)
document body end (readyState=loading; last=null; body.offsetHeight=23808)
document after body (readyState=loading; last=[object]; body.offsetHeight=23808)
defer1 (readyState=loading; last=[object]; body.offsetHeight=23808)
document.onreadystatechange (readyState=interactive; last=[object]; body.offsetHeight=23808)
document.onpropertychange (propertyName=activeElement (srcElement=null); last=[object]; body.offsetHeight=23808)
defer2 (readyState=interactive; last=[object]; body.offsetHeight=23808)
image.onload
document.onreadystatechange (readyState=complete; last=[object]; body.offsetHeight=23808)
window.onload
document.onpropertychange (propertyName=activeElement (srcElement=null); last=[object]; body.offsetHeight=23808)

“defer1” is the inline one, while “defer2” is the external one. The deferred scripts are added in the header:

<script type="text/javascript" defer="defer">
  orderOfEvents[i++] = "defer1 (readyState=" + document.readyState + "; last=" + document.getElementById('last') + ")";
</script>
<script type="text/javascript" defer="defer" src="defer_init.js"></script>

The external deferred script calls init() which has the same code as the inline deferred script.

As you can see, the inline deferred script can access the last element (which is a script element right before the closing html tag) and correctly shows document.body.clientHeight. However, it triggers before readyState changes to “interactive” (if it were not “interactive” already) and before the activeElement property change. For most intents and purposes, this is good enough (activeElement is useless at this point).

I’ve also noticed that when going to the page from another page (i.e. not reloading), readyState is already “interactive” skipping the “loading” state. When reloading, readyState is “loading” until after the inline deferred script runs, at which point it becomes “interactive”. So although readyState is useless for detecting when the DOM is fully loaded, this info could be used elsewhere…

Comment: #50

Good work Maian. I already made a modified test page with deferred scripts included if people want to take a look:

http://dean.edwards.name/my/readyState2.html

Comment: #51

This is odd… When I load http://dean.edwards.name/my/readyState2.html, the deferred inline script executes prematurely. However, when I load of a copy of that page (and the script) onto a server in my company’s LAN, the deferred inline script fires after the document finishes loading.

Here’s my hypothesis: The disparity is caused by the difference between download speed and parsing speed. The parser will parse through the available data, then see if there are any deferred scripts that need executing. On my LAN, the html file is downloaded so quickly that the parser has doesn’t get to check for deferred scripts until after. However, when I download from your site, it’s slow enough that the parser has time to check for deferred scripts.

However, I don’t know why there’s a difference between inline and external deferred scripts. The HTTP request sent for the external deferred script is not delayed – it’s sent before the request to get the image. I also added another external script, this time not deferred, after the deferred external script in the header, and the deferred external script was still requested before the non-deferred external script.

Maybe it’s some server setting? I tried it both on my local server and a server on the LAN. My server runs Tomcat 5.5 on top of Apache2 with mostly default configs. The other server is ISS and I dunno about its settings. In both cases, the deferred inline script executes after the whole document is parsed.

Comment: #52

Maian – the point is, as I mentioned in my original post, it is only a reliable method when using an external deferred script. Despite all the arguments and suggestions to the contrary, my original post describes the only reliable way of using this technique. I just hope that people can be bothered to read all the comments!

To reiterate. Ignore all of the comments to my post. My post describes the only reliable technique for determining if the document has been loaded and parsed on IE/Firefox.

Comment: #53

In what way needs this window.onload script to be adapted so it can be used to handle multiple functions that all need to be fired with the window.onload event as well?

eg referring to the AddLoadEvent function for multiple load events by Simon Wilson

Comment: #54

dean said: To reiterate. Ignore all of the comments to my post. My post describes the only reliable technique for determining if the document has been loaded and parsed on IE/Firefox.

However, this technique doesn’t work too well with Safari. The test page only loads the red banner when the image has finished loading.

It has to do with Safari having the method .addEventListener, but not generating events of type DOMContentLoaded.

I had to stick in a conditional clause testing for Safari (urgh!) in order to get my stuff to load. I’m still testing for what I know is the last object, and that seems to be working pretty well.

Comment: #55

function checkDOM(){
__if (document.getElementById(“footer”)) {
____var func = document.ondomload;
____document.ondomload = function(){};
____func();
__} else {
____setTimeout(“checkDOM();”,100);
__}
}
_
setTimeout(“checkDOM();”,100);
if (document.addEventListener)
__document.addEventListener(“DOMContentLoaded”, checkDOM, null);
if (document.readyState)
__document.onreadystatechange = checkDOM;
//add event
document.ondomload = function(){alert(‘hi there’);}

this will just register to any event that might do the trick, but checks it just in case it’s not correct.

Comment: #56

If this maybe a useful link to this article …
On this page http://www.brothercake.com/site/resources/scripts/domready/ you have a script that use a time-out to check if any DOM script is ready for execution. I found that when using IE WIN (5 and up) and tested a DOM script locally it actually removed the error mesage (JS console) that the element retrieved with the method document.getElementById was undefined.

Comment: #57

Interesting discussion. I wanted to post some snippet but I get an XHTML for the script part
I ripped it off http://www.junit.org/, function jsUnitSetOnLoad(), made some minor changes so it works w/o junit.js as well.

Have fun,
CirTap

Comment: #58

whoops, sorry — wrong URL … http://www.jsunit.net/

Comment: #61

If you’re gonna use a script like this it may not be appropriate to fall back on window.onload – it certainly isn’t appropriate to do that by defualt – because these are two entirely separate points in time, and a script designed to work with one point won’t necessarily work with the other.

For example – a function bound to window.onload can know that any other object on the page has loaded its data as well; so something like an HTML document embedded with an <object> can be used as a data source without having to monitor its load event separately. With a function that fires before onload, this is not the case.

Comment: #62

Who has the “initFunctions” array, where every function that needs to get initialized gets pushed onto that array, then the final onload simply iterates through the functions=

I tried it by myself, but didn´t get it to work. Please help.

Comment: #63

Any special reason why the done property is set on the arguments.callee?

Why not just

init.done = true;

Comment: #64

José – arguments.callee is more generic. If the init function were renamed (or was anonymous) then we would have to change the code.

Comment: #65

Excellent. I applied the “defer” bit to some code for fixing PNG transparency in IE (and also replaced the onload-bit with calling the function immediately).

The result is PNG transparency in IE without any brief initial moment of non-transparency.

Comment: #68

People are writing here for XHTML the defer attribute should be defer=”defer”. But Microsoft’s API documentation states that the value is boolean, and can accept either “true” or “false”. I have no idea whether “defer” will be interpreted as either “true” or “false”. So I would use the non-value (attribute present) non-XHTML style (as in the original posting) or I would use “false” (right?).

MSDN docs on script defer (search “script defer” if the ever-rotting MS links are busted for you).

In any case, I got odd “Illegal Character (Line 2, Character 1)” errors on the HTML file from IE when I used this method, after introducing some CSS to the file via a link element. I had incorporated the conditional compiling instruction into a .js file rather than directly into the HTML file (I would just use the conditional comment version in that case). It was fine without the CSS; the CSS was 100% vanilla (it used some background image URLs is the only remotely advanced part about it).

The conditional comment version fired the script before even the background images loaded for the CSS, which gave an unpleasant hysteresis. So I went to the HTC method and the error and lag went away (perhaps because of CSS loading order). I set media=”screen” to avoid print errors on the HTC’s style element.

I’m too tahred at the moment to provide you with reproducible test cases &c but I thought you might like these reports from the field…thanks very much for sharing these secrets.

Comment: #69

Maybe I don’t quite get it.

Tested both the original and htc versions with my problem page(s).

The original executes the script on all browsers I tried(IE6,Firefox1.0.7, Opera(8.5 and 6.01 (original example waits for page to fully load)),Netscapes 8, 7, and 4.5).

Could only get htc version to work with IE6.

But here’s the real problem for me:

I don’t have ANY images or binary content, just a lot of text (256kb of chemicals).

Behavior is identical with the "solution" as when I use <body onload=…>: it waits until ALL text is loaded.

Anyone have a clue as to how I can get the script running prior to loading?

Comment: #70

I looked at the code and it really works ok. However the thing with winIE did worry me so I altered it: – You don’t have to use an external file for winIE anymore. Instead I used DOM methods to create the javascript. I couldn’t get the browser class in (browser.winIE) in this post because this post system won’t let me but you can imagine how to check for browser.winIE

Look at the code:

  function setupDomLoader(){
    if (document.addEventListener) {
      document.addEventListener("DOMContentLoaded", domLoader, null);
    }
    if (browser.winIE){
      var head = document.getElementsByTagName('HEAD')[0];
      var script = document.createElement('script');
      script.setAttribute('defer','defer');
      script.appendChild(document.createTextNode(domLoader()));
      head.appendChild(script);
    }
    window.onload = domLoader;
  };
  setupDomLoader();

  function domLoader(){
    if (arguments.callee.done){
      return;
    }
    arguments.callee.done = true;

    alert('loaded');
  };

grt, Mark

Comment: #71

Mark – setting the defer attribute does not work. I mention this in my original post.

Comment: #75

I just put all my JS at the bottom the page, then you can see everything above it. Am I a bad man?

Comment: #78

What about a single initializing-script ?

<script defer src=”init.js”></script>

init.js will contain helper-code for Mozilla/Other browsers and simply run init() in case of ie.

Comment: #79

Getting this to work in Safari involves an involved object detect in the if(document.addEventListener) code:

if(document.addEventListener &&
  !(!document.all && document.childNodes && !navigator.taintEnabled)){
	document.addEventListener('DOMContentLoaded', domInit, null);
}
else{
	addEvent(document, 'load', domInit);
}

An alternative would be to specifically detect Mozilla / Firefox to the exclusion of others, which would probably be as nasty.

Comment: #80

Additional: Just discovered that this doesn’t suit Opera 8.51 (grr), so another check is required:

if(document.addEventListener && !window.opera &&
  !(!document.all && document.childNodes & & !navigator.taintEnabled))

Comment: #82

Thanks Dean, I’ve been having trouble passing variables to a flash applet (in Firefox only) and have been resorting to setTimeout() functions for waiting 200 msecs before passing the values from JavaScript. This trick provides better performance for many applets.

Comment: #83

Ok.. I saw this and I was intrigued, but then I started thinking, why are you bothering with this. If you have already gone far enough to disregard accessibility by using DOM scripting why not just build the entire page with your scripts. That way there is no Images to wait for, your script should execute right away. You can start build up the page imediately and not have to worry about flaky methods of learning when the page is loaded.

Am I crazy here?

Comment: #84

Paul – ‘disregard accessibility by using DOM scripting’? When written properly (and thoughtfully), DOM scripting will only provide enchancements to the browsing experience, not hinder accessibility of the content itself. That’s what graceful degradation is all about.

Don’t dismiss a technology purely because of it’s potential for misuse.

Comment: #85

Agreed. That is exactly what I’ve used this for; a Bobby AAA compliant page that has scrolling news should you be running JavaScript without any flicker as it gets implemented from the original content, or a nice unordered list if you aren’t (or aren’t running IE>=5 [Win], Mozilla, Safari, Opera 8, Camino etc., hell those users don’t even get a stylesheet).

What annoys me is people who deliberately cripple a browser in a way that doesn’t reflect real-world usage and then bleat “I couldn’t use your site, you’re not accessible” when the real audience have no problem. And they’re everywhere, claiming to be an “accessibility advocate”, which they aren’t. That would be me

Comment: #86

I haven’t put this through the rounds of x-browser testing yet, but it looks good so far. The solution could be extended by implementing an Observer Pattern:

window.onloadListeners = new Array();

window.addOnLoadListener = function(listener) {
	window.onloadListeners[window.onloadListeners.length]=listener;
}

function init() {
       // quit if this function has already been called
       if (arguments.callee.done) return;

       // flag this function so we don't do the same thing twice
       arguments.callee.done = true;

       // iterates through array of registered functions 
       for (var i=0; i<window.onloadListeners.length; i++) {

		var func = window.onloadListeners[i];
		func();
	}
 };

that way javascript includes, etc could register themselves using:

window.addOnLoadListener(YourFunctionName);

Comment: #90

Kinda hacky, but worth every bit. This rocks.

Thanks Dean!

Comment: #91

Dude. I’m a hacky kinda guy.

Comment: #92

You can’t depend on document.addEventListener to find moz, since it exists in other browsers. Try this:

if ( window.controllers ) document.addEventListener(‘DOMContentLoaded’, initMain, false); } ….

Thanks ydnar!

By the way, your email checking is busted, plus is allowed in emails: http://en.wikipedia.org/wiki/Email_address#Plus_addressing

Comment: #93

is there something wrong with:

var addLoadEvent = function(func){
if (window.addEventListener) {
  window.addEventListener('load', func, false);
} else {
  window.attachEvent('onload', func);
}

this works in every browser I’ve tested it in.
And, if nothing else, you can fallback to something like:

if (window.onload) {
  var func = window.onload;
  window.onload = function() {
    whatever here
    func();
  }
}

Comment: #94

@David – we don’t need to detect Mozilla specifically. If DOMContentLoaded is not supported then nothing will happen and we will revert to the original onload event.

@Jeremy – You seem to have completely missed the point of this solution.

@Everyone – I’m closing comments on this post now. The later comments are at best pointless and at worst misleading. I’m not going to waste my precious bandwidth uploading more of the same.