Orlok: Event-Handler !== Event-Typ && Gliederung

Beitrag lesen

Hallo

Also, zunächst mal vielen Dank @Matthias Scharwies dafür, dass er sich nach meiner Kritik direkt an die Arbeit gemacht hat, um die (meiner Ansicht nach) gröbsten Defizite zu beseitigen! ;-)

Leider wird es wegen meines Studiums noch etwas dauern bis ich die Zeit habe, mich in angemessener Weise um den Artikel zum Thema Event-Handling zu kümmern, aber es gibt da eine Sache, die ich doch noch einmal ansprechen möchte, da ich glaube, dass sie - so wie es momentan im Wiki umgesetzt ist - nach wie vor das Potential besitzt, bei den Lesern für Verwirrung zu sorgen:

Nämlich die fehlende beziehungsweise mangelhafte Unterscheidung von Event-Typ und Event-Handler.

Naja, jedenfalls damit klar wird, worauf ich hier hinaus will, zunächst einmal ein kurzer Abriss zur Historie:

(1) Event-Handler als HTML-Attribute

Früher™, und damit meine ich ganz früher, war ja die einzige Möglichkeit des Event-Handlings die heute zurecht als bad practice gebranntmarkte Registrierung von Handlern in Form von HTML-Attributen, also nach dem Schema:

<p onclick="handler( );">

Das heißt, man hinterlegt in einem HTML-Attribut den auszuführenden JavaScript-Code als String, der dann zu einem Function-Body einer anonymen Funktion verwurstet wird, so dass am Ende im Idealfall so etwas wie das hier dabei herauskommt:

onclick = function ( ) {
  handler( );
};

(2) Event-Handler als Eigenschaftswert von DOM-Objekten

Aufgrund der vielen Nachteile die mit dieser Methode verbunden sind, von denen man aber damals, bis auf die unvorteilhafte Vermischung von HTML und JavaScript, die meisten wohl noch nicht auf dem Schirm hatte, hat man also dieses Schema dann einfach mehr oder weniger auf JavaScript übertragen.

Das heißt, statt den auszuführenden Code als Wert eines HTML-Attributes zu hinterlegen, hat man nun direkt in JavaScript einer Objekteigenschaft eine Handler-Funktion als Wert zugewiesen:

element.onclick = handler;

Auch wenn diese Übersetzung nach JavaScript einige Veränderungen mit sich gebracht hat, handelt es sich hierbei doch intern um die gleiche Eigenschaft, wie man sehr gut daran sehen kann, dass…

<p onclick="handler( );">

durch

p.onclick = null;

…überschrieben wird.

In beiden Fällen würde man hier nun beispielhaft von einem onclick-Handler sprechen, und dabei wahlweise den Bezeichner der Eigenschaft, deren Wert, oder in der Regel beides zusammen meinen, wobei mit der Bezeichnung Handler eben schlicht die jeweilige Routine zur Verarbeitung des Ereignisses gemeint ist, was global betrachtet die konkrete Implementierung im Browser mit einschließt, bezogen auf das JavaScript-Programm im engeren Sinne jedoch den als Eigenschaftswert hinterlegten Code meint.

Aber wie dem auch sei, haben diese beiden Arten des Event-Handlings jedenfalls kaum je Anlass dazu gegeben, sprachlich strikt zwischen dem jeweiligen Handler-Attribut und dem dazugehörigen Event-Typ zu trennen, das heißt, so wie es bis zu Matthias' Umbenennungsaktion auch hier im Wiki der Fall war, hat man die unterschiedlichen Event-Typen eben üblicherweise mit den dazugehörigen Attributbezeichnern assoziiert.

Sprich, auch wenn es schon immer formal richtiger gewesen wäre, die einzelenen Event-Typen, wie etwa load, click oder focus auch als solche aufzulisten, und die Methodik um diese anzusprechen separat als element.on + type zu beschreiben, ist es jedenfalls dennoch nicht völlig unverständlich, dass die einzelen Attributbezeichner hier direkt aufgelistet wurden, also in Form von onload, onclick, onfocus, usw…

(3) Methode statt Eigenschaft: addEventListener

Jedenfalls, schließlich und glücklicherweise, wurde durch die Standardisierung durch das W3C ein weiteres, besseres Modell zur Ereignisbehandlung hinzugefügt, nämlich die Methode addEventListener und - dieser zugrundeliegend - die Schnittstellen Event, Event Target und Custom Event.

object.addEventListener( 'event', callback [, capture] );

Ich denke wir sind uns alle einig, dass, abgesehen von einigen seltenen und gut begründeten Ausnahmen, dies die Art des Event-Handlings ist, die den Lesern des Wikis zu verwenden nahegelegt werden sollte.

Im Gegensatz zu den traditionellen Methoden des Event-Handlings - und übrigens auch im Gegensatz zu Microsofts obsoleter Spezialsyntax mit attachEvent - entfällt hier nun das Prefix on und der spezifizierte Typ des Ereignisses wird als erstes Argument der Methode direkt notiert.

So. Und diese Diskrepanz zwischen der berechtigterweise empfohlenen Methode addEventListener, welche den Typ des Events als Parameter entgegennimmt und der Tatsache, dass bis zum beherzten Eingreifen von Matthias Scharwies lediglich die Attributbezeichner, beziehungsweise die Event-Handler im Wiki aufgelistet waren, war letztlich der Grund für den eingangs von mir verlinkten Beitrag.

Aber warum nun dieser Beitrag? Nicht alles gut?

Leider noch nicht ganz! ;-)

Aus genannten Gründen war die Struktur des Wikis in diesem Zusammenhang veraltet, aber sie war zumindest nicht falsch, jedenfalls nicht insoweit man sprachlich nicht zwischen den Eigenschaftsnamen und den eigentlichen Handler-Funktionen unterscheidet.

So wie es aber im Moment ist, sind zwar richtigerweise die Events unter ihren Typ-Bezeichnern aufgelistet, aber die Rubrik heißt immernoch Event-Handler und sowohl der Einleitungstext…

„Event-Handler (Ereignisbehandler) sind ein wichtiges Bindeglied zwischen HTML und JavaScript. Event-Handler werden entweder in Form von Attributen in HTML-Tags notiert (siehe auch HTML/Eventhandler), besser aber mittels der Methode addEventListener hinzugefügt.“

…als auch die tabellarische Darstellung der einzelen Events sprechen bezogen auf den Bezeichner nach wie vor von Handlern, wo doch bezogen auf den aktuellen Inhalt nunmehr eigentlich der Typ gemeint ist. ;-)

Die Frage, die ich mir stelle ist also folgende: Wie und wo sollen die einzelnen Event-Typen im Wiki aufgeführt werden?

Wie gesehen waren aus historischen Gründen die Event-Handler bislang korrekt und an prominenter Stelle aufgelistet, und rein formal betrachtet wäre es ja auch nicht falsch gewesen, sie, statt die Prefixe zu entfernen, einfach genau dort zu lassen, zumal diese Form des Event-Handlings ja nicht offiziell deprecated ist.

Jedenfalls wäre es meiner Ansicht nach formal die sauberste Lösung, die einzelenen Event-Typen auch unter der Rubrik Event aufzulisten, wobei links über Eigenschaften und dem Block mit altKey usw. ein optisch abgesetzter Link Event-Typen oder Die verschiedenen Events stehen sollte, der dann auf die Seite mit der Liste führt.

Das hätte zwar den Nachteil der tieferen Verschachtelung, aber es wäre erstens formal richtig und zweitens wären all die Informationen über das moderne Event-Handling in einer Rubrik „Event“ konzentriert.

Und was die traditionellen Methoden angeht, was soll damit passieren? ;-)

Ich denke, eine Auflistung aller Attributbezeichner, egal ob HTML oder DOM, können und sollten wir uns sparen!

Statt dessen wäre ich dafür, vielleicht unter der Rubrik Window oder Elemente einen Link zu setzen und auf der entsprechenden Seite einfach kurz und knapp zu erklären, wie die Handler-Funktionen als Objekteigenschaften hinterlegt werden können, also object.on + 'typeString' = handlerFunction; mit Verweis auf die Liste der einzelnen Event-Typen.

Also…

JavaScript > DOM > Events > Typen | Eigenschaften | Methoden [Event-Handling + Event-Delegation]

JavaScript > DOM > Elemente [?] > Event-Handler [Kurze Erklärung + Verweis]

HTML > Event-Handler [Kurze Erklärung + Verweis]

…wäre in etwa mein Vorschlag zur Gliederung. ;-)

Würde mich freuen zu hören wie ihr das seht!

Gruß,

Orlok

akzeptierte Antworten