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

[Roker]

Was ist der Vorteil, Eventhandler erst nach dem Laden der Seite per JavaScript hinzuzufügen, anstatt direkt "onload" usw. im HTML-Code zu haben?

Ein Browser, der kein JavaScript ausführt, stört sich nicht an diesen Attributen. Alle anderen können sofort den fertigen DOM-Tree aufbauen, ohne dass hinterher noch einmal mit JavaScript drübergegangen werden muss, um überall die passenden Handler anzuflanschen. Letzteres ist zudem fehlerträchtig, etwa wenn man sich mal in der ID eines Elementes vertippt oder wenn bei Änderungen im HTML-Code übersehen wird, die externe .JS-Datei auch anzupassen usw.

Besser ist es also IMHO, wenn alles, was zu einem HTML-Element gehört, auch direkt dabei steht und nicht im Nachhinein von fernem Code unerwartet manipuliert wird.

[dedlfix]

Tach!

Was ist der Vorteil, Eventhandler erst nach dem Laden der Seite per JavaScript hinzuzufügen, anstatt direkt "onload" usw. im HTML-Code zu haben?

Mit "Trennung von Zuständigkeiten" kann man diese Vorgehensweise kurz umschreiben. Man hat alles beisammen an einem Ort und nicht überall verteilt.

Ein Browser, der kein JavaScript ausführt, stört sich nicht an diesen Attributen. Alle anderen können sofort den fertigen DOM-Tree aufbauen, ohne dass hinterher noch einmal mit JavaScript drübergegangen werden muss, um überall die passenden Handler anzuflanschen.

Ob gleich oder hinterher nimmt sich ja nicht viel, es muss in beiden Fällen getan werden. Lediglich der Teil "Suchen des Elements" fällt weg, und den haben die Browserhersteller hoffentlich gescheit optimiert.

Letzteres ist zudem fehlerträchtig, etwa wenn man sich mal in der ID eines Elementes vertippt oder wenn bei Änderungen im HTML-Code übersehen wird, die externe .JS-Datei auch anzupassen usw.

Ja, aber solche Fehler können auch abseits der Eventhandler auftreten. Du möchtest dich ja vielleicht im Eventhandler auf andere Elemente beziehen, und auch da muss der Name (oder allgemein der Selektor) passen. Aufpassen musst du bei Änderungen also immer. Da kann solch ein Ruhekissen auch negative Auswirkungen haben.

Besser ist es also IMHO, wenn alles, was zu einem HTML-Element gehört, auch direkt dabei steht und nicht im Nachhinein von fernem Code unerwartet manipuliert wird.

Aber dann auch bitte konsequent mit CSS. Wenn Elemente einen individuellen Style bekommen sollen, dann schreib ihn zu jedem Element einzeln in die style-Angabe. - Nicht! - Bei dieser Argumentation solltest du sehen, dass es zumindest ab einem bestimmten Punkt nicht mehr sinnvoll ist, eine individuelle Konfiguration statt einer zentralisierten zu haben. Bei den Eventhandlern, die ein Single-Leben führen, mag man das ja noch vertreten können. Generell werden da wohl vorwiegend Konsistenzgründe genannt werden. Wenn wir schon überall trennen, können wir das an der Stelle auch durchziehen.

Es gibt aber auch noch ein paar technische Gründe, beispielsweise, dass man an das Element mit HTML nur einen Eventhandler anbringen kann, mit Javascript aber beliebig viele. Und einige Ereignisse haben gleich gar keinen Ansatzpunkt im HTML.

dedlfix.

[Gunnar Bittersmann]

@@dedlfix

Lediglich der Teil "Suchen des Elements" fällt weg, un den haben die Browserhersteller hoffentlich gescheit optimiert.

So in der Art? ☞ Frage im Folgeposting

LLAP 🖖

[dedlfix]

Tach!

Lediglich der Teil "Suchen des Elements" fällt weg, un den haben die Browserhersteller hoffentlich gescheit optimiert.

So in der Art? ☞ Frage im Folgeposting

Daran dachte ich beim Schreiben des Satzes. Inwieweit das allerdings optimiert ist, ob man mit dem einen oder anderen Hack was bewirken kann, und ob das auch in allen Browsern gleich gut aussieht, will ich nicht nachforschen. Am Ende läuft das auf nicht wirklich beeinflussbare Mikrooptimierung raus, und da ist mir die Lesbarkeit des Codes doch deutlich wichtiger.

dedlfix.

[Matthias Apsel]

Hallo dedlfix,

Es gibt aber auch noch ein paar technische Gründe, beispielsweise, dass man an das Element mit HTML nur einen Eventhandler anbringen kann, mit Javascript aber beliebig viele.

Nicht?

<p onclick="location.reload()" onfocus="location.reload()">Reload</p>

Du meinst einen Handler pro event 😝

Bis demnächst
Matthias

[JürgenB]

Hallo,

oder

<p onclick="tu_dies(); tu_das()">Tu was</p>

Gruß
Jürgen

[Christian Kruse]

Hallo JürgenB,

<p onclick="tu_dies(); tu_das()">Tu was</p>

Wenn wir schon Korinthen kacken: das ist nur ein Event-Handler. Es werden zwei Funktionen aufgerufen, aber es ist nur ein Event-Handler! 😉

LG,
CK

[JürgenB]

Hallo Christian,

<p onclick="tu_dies(); tu_das()">Tu was</p>

Wenn wir schon Korinthen kacken: das ist nur ein Event-Handler. Es werden zwei Funktionen aufgerufen, aber es ist nur ein Event-Handler! 😉

mein alter addEvent() hat aber genau das gemacht. 😎

Gruß
Jürgen

[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

[Gunnar Bittersmann]

@@Rolf B

haben sich Leute ausgedacht, die GROẞE Seiten mit viel Script bauen

Ein großes ẞ in freier Wildbahn! ❤️

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.

Welchen Sinn hat denn ein DOMContentLoaded-Handler in einem Script am Ende des body?

• DOMContentLoaded-Handler irgendwo: Handlerfunktion wird aufgerufen, nachdem das HTML geparst wurde.

• Script am Ende des body: wird aufgerufen, nachdem das HTML geparst wurde.

LLAP 🖖

[Christian Kruse]

Hallo Gunnar,

• Script am Ende des body: wird aufgerufen, nachdem das HTML geparst wurde.

Praktisch: ja. Technisch kommt da noch Whitespace + </body> + Whitespace + </html> 😉

*scnr*

LG,
CK

[pl]

Besser ist es also IMHO, wenn alles, was zu einem HTML-Element gehört, auch direkt dabei steht und nicht im Nachhinein von fernem Code unerwartet manipuliert wird.

Ne, sehe ich anders. Nämlich unter Aspekten der Wartungsfreundlichkeit und Skalierbarkeit. Des Weiterung unter dem Aspekt Coderedundanzen.

Besser ist es also IMHO, wenn alles, was zu einem HTML-Element gehört, auch direkt dabei steht

Nunja, wenn man style="width:100%" ein zweitesmal irgendwo hintippt, sollte es eigentlich Klick machen 😉

(Auch wenn es IDE gibt die sowas unterstützen!)

MfG