Wieso sollen JavaScript-Eventhandler nicht im HTML-Code stehen?

[Rolf B]

Hallo Roker,

ergänzend noch ein paar weitere Dinge.

Der „onload ist doch viel einfacher“ Ansatz ist nachvollziehbar, solange man Webseiten mit ganz wenig Script hat. Sobald das umfangreicher wird, explodiert diese Vorgehensweise. Prinzipen wie "Trennung der Zuständigkeiten" oder "unaufdringliches JavaScript" haben sich Leute ausgedacht, die GROẞE Seiten mit viel Script bauen, und die ihre Projekte ohne diese Prinzipien nicht beherrschen könnten.

Ein onxxx Attribut enthält einen einzeiligen String. Das ist eigentlich keine gesunde Umgebung für JavaScript, weil damit eine Kategorie von Anführungszeichen weg ist, und eine lesbare Codedarstellung nicht möglich ist. Deswegen schreibt man in diese onxxx-Attributen nicht mehr hinein als einen Funktionsaufruf.

Das führt zum nächsten Problem: globale Elemente. Die Funktionen, die man aus onxxx Attributen heraus aufruft, müssen global sichtbar sein. Zumindest musst Du ein globales Objekt anlegen, das diese Handlerfunktionen als Methoden anbietet. Das hindert Dich daran, deine Scripte zu modularisieren.

Speziell bei einem onload Handler gilt: das Script muss geladen sein, bevor das onload-Attribut vom Browser gefunden wird. D.h. entweder hast Du dein onload-Script im Head stehen, oder lädst es von dort mit script src=.... Was bedeutet: Dein Seitenaufbau hängt, bis das Script da ist. Mit einem DOMContentLoaded-Handler, der in einem Script am Ende des Body registriert wird, bist Du besser bedient. Der Punkt ist hier: schneller Seitenaufbau, den Anwender nicht vor einem weißen Bild warten lassen. Wenn der load-Handler (genauer: der DOMContentLoaded Handler) wichtige Dinge an der Seite verändert, dann muss die Seite so dargestellt werden dass der Anwender vor Abschluss dieser Veränderung eine "bitte etwas Geduld" Anzeige erhält.

Rolf