Hej, skönt att allt löste sig.
Några saker jag tänkte på bara som inte helt kommit fram i kommentarerna (det mesta vet du säkert redan)

Själv använder jag web developer toolbar i FireFox för att debugga min JavaScript. Rekommenderar den skarpt.

En sak du bör ha som vana när du skriver JavaScript, precis som all annan kod, för att undvika krockar etc (som du trodde var det ursprungliga felet) är att använda dig av namespaces/classer och object.

En tredje sak jag tänkte på och här får någon annan gärna bekräfta eller dementera mina uppgifter då jag absolut inte alls är säker. Det är att det finns vissa risker med att använda window.onload
Det är visserligen en lösning som jag gillar med den även kan lägga init-triggern i de externa JavaScript filerna. Men om jag nu minns rätt (och här får någon annan som sagt gärna också säga sitt) så väntar wondow.onload med att triggas tills allt på sidan har laddats in, alltså även bilder etc.
Det betyder att har du en tung bild som ska laddas eller om användaren sitter på en seg uppkoppling kan det ta flera sekunder innan din init funktion kör igång.

Oftast räcker det med att dom:en har laddat för att dina javascript ska fungera. Då kan du med fördel starta din init funktion i slutet av html-koden.
Vet att alla där ute inte håller med mig om att detta är den ultimata lösningen. Det är i alla fall så jag oftast brukar göra.

Att starta Javascript innan sidan laddat klart kan resultera i div. problem, olika webbläsare kan då starta då scriptet vid olika tillfällen, t.ex. en getElementByid() kan ge ett null-resultat i vissa läsare. Med windows.onload får man en lösning som är betydligt mer crossplatform-vänlig och stabil.

Ja, absolut om inte domen är laddad kommer du få problem att nå dina html-objekt, kallar du dock på init-javascript-funktionen i slutet av sidan, alltså efter att all html är inladdad bör det inte vara några problem. I alla fall har jag aldrig haft några problem med detta i någon av de webbläsare jag har provat.
Men det är möjligt att det kan uppstå problem i något scenario där js-filerna inte hunnit laddas in eller. Jag har dock aldrig stött på detta problem och det är enkelt avhjälpt med en try/catch samt en onload backup trigger (om problemet skulle uppstå). Däremot har jag stött på problem med att onload tagit för lång tid på sig att triggas, exempelvis om en bild laddas från en extern sida som inte längre finns och användaren klickar på en knapp som ska trigga något JavaScript.

onload innebär att det blir onödiga och märkbara fördröjningar som i.o.f.s. är acceptabelt för en del men ganska onödigt egentligen. DomContentLoaded körs mkt tidigare än onload. Idag finns det bättre alternativ. Man kan t.ex. kombinera ett modultänk med Jans tankar om att anropa init längst ned innan </body></html> och då får man nog en av de snyggare lösningarna.

DomContentLoaded är inte något som jag skulle använda eftersom det är många webbläsare som det inte fungerar i. Att lägga scriptstarten i slutet av bodyn fungerar ofta, men det fungerar inte i alla lägen. Kör du plugins (t.ex Java applet) så kan man få problem i vissa webbläsare.

Vilka webbläsare menar du när du skriver många? Äldre versioner av IE vet jag om men resten av de moderna webbläsarna ska det ju funka i.

Ja, alla IE förutom 9:an. Dvs. runt 15-20% av besökarna på en "normal" hemsida.

Tack. Jag hade för mig att MS lade in stöd för eventet i IE 8... fasligt vad snabbt man glömmer bort saker och ting när man använder libs.

IE-läsarna historiska "inkompabilitet" har nog ställt till med många timmars onödigt jobb för folk i branschen :)

Eller så använder man ett vettigt bibliotek och får fullgott stöd för emulation av domcontentloaded för browsers som inte stödjer det.

Men om man gärna vill återuppfinna hjulet med detta, liksom mycket annat, och göra det manuellt får man:
För IE lägga en conditional statement som kör document.write av en script-tagg, och sen kolla readystate på scriptet.
För Safari lägga en timer som kollar document.readyState