[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.

[SimonP]

Ursprungligen postat av dAEk

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

[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.