Hallo Matthias

Wäre dann eine Umbenennung von JavaScript/Event-Handler in JavaScript/Events oder JavaScript/Event-Typen und eine prominente Verlinkung von JavaScript/Objekte/DOM/event auf diese Seite entweder

• als Box oder

• im Text [[JavaScript/Events - Anwenderereignissen wie Mausklicks oder Tasteneingaben]]

besser?

Tja, wie das am besten zu gliedern sei, dass war ja meine Frage, und mehr als meine Sicht der Dinge zu schildern und Vorschläge zu machen steht mir hier ja auch nicht zu… ;-)

Die Sache ist einfach die, dass ich der Ansicht bin, dass es dem Wiki gut zu Gesicht stehen würde, wenn sowohl sprachlich als auch von der Struktur her klar zwischen Events und Methoden des Event-Handlings differenziert wird.

Nehmen wir als Beispiel einmal das Event click:

Dieses Event ist spezifiziert, und zwar unabhängig von den Event-Handlern.

Wenn wir also über die Eigenschaften des Events click sprechen, dann betrifft dies im Wesentlichen die in der Schnittstelle Event definierten Attribute des Events selbst, wie etwa event.cancelable oder event.bubbles, wobei die Werte, mit denen diese Eigenschaften durch die Konstruktorfunktionen des Browsers initialisiert werden, dann wiederum für den speziellen Typ des Events definiert sind.

Dies sind also Eigenschaften des Events, aber die Event Handler wie etwa onclick, egal ob nun im Kontext von HTML oder JavaScript, sind davon unabhängig zu betrachten.

Was aber nicht bedeutet, dass für die individuellen, also die mit den einzelnen Events assoziierten Event-Handler, wie eben onclick, auch zwingend eine eigene Seite zur Verfügung gestellt werden müsste.

Ich denke, Besonderheiten bezüglich dieser Handler-Attribute können und sollten durchaus innerhalb des Tabellenlayouts bei den jeweiligen Event-Typen untergebracht werden, nur eben in einer Form die klar macht, dass diese Informationen eben zum Handler des Events, nicht aber zum Event selbst gehören.

Ich meine, es ist sprachlich schon einigermaßen verwirrend: Natürlich kann man sagen, dass ein mittels der Methode addEventListener für den Event-Typ click hinzugefügter Handler ein click-Handler ist, ebenso wie es nicht völlig falsch wäre, einen Mittels der traditionellen Methode registrierten Attribut-Handler onclick einen onclick-Handler zu nennen, aber im Kern geht es in beiden Fällen um einen Handler für das Event click, welches eben nicht mit der Methode identisch ist.

Tja, und dieses Verwirrungspotential ist nun gerade der Grund, weshalb ich hier so vehement für eine klare sprachliche und strukturelle Abgrenzung plädiere. ;-)

Ich bin also dafür, sich hier möglichst nah am W3C-Standard zu orientieren, sprich im Zentrum sollten nicht mehr so wie früher die einzelnen, mit den jeweiligen Event-Typen assoziierten Event-Handler wie etwa onclick oder onload stehen, sondern die spezifizierten Typen von Events selbst, zumal es ja auch deren Typbezeichner sind, welche den nach dem W3C-Modell hinzugefügten Event Listenern als steuernde Parameter dienen, und welche der Methode addEventListener prominent als erstes Argument in Form eines Strings übergeben werden.

Von daher bin ich wie gesagt dafür, die Liste der verschiedenen Events unter der Rubrik DOM/Events gleich an erster Stelle aufzuführen und eventspezifische Besonderheiten hinsichtlich der traditionellen Attribut-Handler dann auf den Seiten der jeweiligen Events gesondert auszuzeichnen.

Die traditionellen Methoden des Event-Handlings selbst sollten dann nur noch allgemein beschrieben werden, also in dem Sinne von element.on + eventType = handler; beziehungsweise für HTML-Attribute <element on + eventType="handler( );">, wobei die HTML-Variante durchaus da bleiben kann wo sie momentan ist.

Die JavaScript-Variante unterzubringen ist da schon schwieriger, und ich bin fast der Ansicht, dass die allgemeine Beschreibung der Hinterlegung von Handler-Funktionen in Objekteigenschaften ebenfalls unter DOM/Events verlinkt werden sollte, vielleicht direkt und der dem Link zur addEventListener-Methode.

Das wäre zwar formal nicht wirklich sauber, aber das ist der Link zur Seite über die Methode addEventListener an dieser Stelle auch nicht, zumal dies eine Methode der Schnittstelle EventTarget ist, welche ja nicht den Event-Objekten vererbt wird, sondern den DOM-Objekten, also Document und den Elementen sowie darüber hinaus auch Window.

Aber ich halte es dennoch für sinnvoll, diese beiden Methoden an dieser Stelle aufzulisten, zumal dann an einer Stelle alle wichtigen Informationen konzentriert sind.

Gruß,

Orlok