[Jan]

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.

[SimonP]

Ursprungligen postat av Jan

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.

[Jan]

Ursprungligen postat av SimonP

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.

[dAEk]

Ursprungligen postat av SimonP

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.

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.

[SimonP]

Ursprungligen postat av dAEk

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.

[dAEk]

Ursprungligen postat av SimonP

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.

[SimonP]

Ursprungligen postat av dAEk

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.

[dAEk]

Ursprungligen postat av SimonP

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.

[Clarence]

Ursprungligen postat av SimonP

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.

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

[Jan]

SimonP & dAEk
Hahaha ja det är hemskt vad folk är sega på att uppgradera sina webbläsare
Det är galet att 9.7% av världens surfare fortfarande sitter på ie6 (källa: http://www.ie6countdown.com/)
Riktar man sig dock bara mot svenska och nordiska marknaden kan man äntligen skippa stöd för denna Lucifer skapelse, men riktar man sig mot asien och kina så är det bara att slita av sig håret i frustration.

ie6 fyller för övrigt 10 år i morgon (27 augusti) man kanske skulle anordna ett litet kalas


Clarence
Nja håller inte helt med. Färdiga bibliotek kan vara bra ibland, men det är onödigt att koppla på ett tungt bibliotek om det bara är en liten funktionalitet man behöver.
Sen är det stor kvalitetsskillnad på olika bibliotek och det är inte alltid de är välkodade, samt finns det buggar i biblioteket kan de vara svåra att lösa. JavaScript är lite undantaget, eftersom du har tillgång till all kod där och faktiskt kan gå in och fixa buggarna själv. Men har ett antal gånger råkat ut för slutna .net och actionscript bibliotek som haft buggar i sig och du därför måste skapat en workaround för att minimera problemet.

Det var fortfarande rätt beslut att använda de biblioteken eftersom de sparade mycket utvecklingstid. Min poäng är bara att ett stort bibliotek inte alltid är bästa lösningen och därför kan det vara klokt att diskutera fram en bra lösning på onload-problemet samt att bara för att ett bibliotek är känt eller kostar pengar betyder inte det att det inte har buggar eller andra problem.