Hallo Klaus1, es ist grundsätzlich falsches Design, Klicks auf ein `div` zur Steuerung einzusetzen. Das Problem besteht darin, dass die Seite dann eine Tastaturnutzung ausschließt, sprich: einen Fehler in der Bedienbarkeit hat. Das, was Dir gerade auf die Füße fällt, ist ein anderes Problem: Click-Ereignisse unterliegen dem Event-Bubbling, d.h. nach dem Element, auf das geklickt wurde, läuft das Event auch an allen Eltern-Elementen vorbei. Es gibt zwei Möglichkeiten, damit umzugehen: 1. Unterbinde das bubbling des Events - dazu müsstest Du einen Event-Listener auf dem a Element haben, der auf dem Event-Objekt die stopPropagation Methode aufruft. Das ist aber sehr umständlich, weil Du ja für deine Fachfunktionen gar keinen Eventhandler auf dem a Element brauchst. 2. Erkenne im click-Handler für das div, ob der Klick für das div bestimmt war oder für ein Kind-Element des div (mittels der target und currentTarget-Eigenschaften des Event-Objekts). Aber noch besser ist es, wenn Du zum an- und abwählen Buttons einsetzt, die sind bedienbar und dafür gedacht, Funktionen auf der Seite auszulösen. Es ist auch intuitiver, einen Button zu klicken, statt irgendwohin in ein div. Die Alternative Checkbox zum Button wäre auch noch zu betrachten - als "Ein-/Ausschalter" ist eine Checkbox eigentlich ganz praktisch; und per CSS kannst Du eine nicht angehakte Checkbox auch dazu verwenden, die Inhalte der Module zu verstecken oder zu deaktivieren. Das hängt jetzt von deinen Anforderungen ab. Ein click-Event auf ein div zu registrieren ist nicht prinzipiell falsch. Aber es nicht dafür gedacht, Klicks auf das div selbst zu verarbeiten. Wenn ich bspw. ein DIV habe mit 17 Buttons drin, von denen ggf. noch welche dynamisch hinzukommen, dann kann ich das click Event auf dem div registrieren und bekomme mit einer Registrierung alle Events mit, und das sogar für Buttons, die nach der Registrierung dazu gekommen sind. Über die target-Eigenschaft des event-Objekts, das ein click-Handler bekommt (wenn man ihn über addEventListener registriert) findet man dann den geklickten Button heraus. Bei einer Event-Registrierung über das onclick-Attribut musst Du Dir das Event-Objekt beschaffen, sonst hat der Handler es nicht zur Verfügung. Das geht so: ~~~ <div onclick="moduleClicked(event)"> ... </div> ~~~ Die Variable `event` enthält in dem Moment, wo der Klick verarbeitet wird, das Event-Objekt. Ein mit addEventListener registrierter Handler bekommt das Event-Objekt automatisch. Eine generische Modulsteuerung würde diesen click-Handler auch nicht auf jedem Modul registrieren, sondern auf dem gemeinsamen Container aller Module. Wenn dieser click-Handler dann feststellt, dass ein Button gedrückt wurde der ein Modul ein/ausschaltet, sucht er in der Eltern-Hierarchie des Buttons das betreffende Modul-Div (welches bspw. an einer class erkennbar wäre) und führt dann die Aktivierung oder Deaktivierung durch. Eine Registrierung, eine Funktion, kein Schmutz im HTML. Eventuell wäre dann auch das section-Element eine gute Alternative zum div. _Rolf_ -- sumpsi - posui - clusi

Hallo Klaus1, es ist grundsätzlich falsches Design, Klicks auf ein `div` zur Steuerung einzusetzen. Das Problem besteht darin, dass die Seite dann eine Tastaturnutzung ausschließt, sprich: einen Fehler in der Bedienbarkeit hat. Das, was Dir gerade auf die Füße fällt, ist ein anderes Problem: Click-Ereignisse unterliegen dem Event-Bubbling, d.h. nach dem Element, auf das geklickt wurde, läuft das Event auch an allen Eltern-Elementen vorbei. Es gibt zwei Möglichkeiten, damit umzugehen: 1. Unterbinde das bubbling des Events - dazu müsstest Du einen Event-Listener auf dem a Element haben, der auf dem Event-Objekt die stopPropagation Methode aufruft. Das ist aber sehr umständlich, weil Du ja für deine Fachfunktionen gar keinen Eventhandler auf dem a Element brauchst. 2. Erkenne im click-Handler für das div, ob der Klick für das div bestimmt war oder für ein Kind-Element des div (mittels der target und currentTarget-Eigenschaften des Event-Objekts). Aber noch besser ist es, wenn Du zum an- und abwählen Buttons einsetzt; die sind bedienbar und dafür gedacht, Funktionen auf der Seite auszulösen. Es ist auch intuitiver, einen Button zu klicken, statt irgendwohin in ein div. Ein click-Event auf ein div zu registrieren ist nicht prinzipiell falsch. Aber es nicht dafür gedacht, Klicks auf das div selbst zu verarbeiten. Wenn ich bspw. ein DIV habe mit 17 Buttons drin, von denen ggf. noch welche dynamisch hinzukommen, dann kann ich das click Event auf dem div registrieren und bekomme mit einer Registrierung alle Events mit, und das sogar für Buttons, die nach der Registrierung dazu gekommen sind. Über die target-Eigenschaft des event-Objekts, das ein click-Handler bekommt (wenn man ihn über addEventListener registriert) findet man dann den geklickten Button heraus. Bei einer Event-Registrierung über das onclick-Attribut musst Du Dir das Event-Objekt beschaffen, sonst hat der Handler es nicht zur Verfügung. Das geht so: ~~~ <div onclick="moduleClicked(event)"> ... </div> ~~~ Die Variable `event` enthält in dem Moment, wo der Klick verarbeitet wird, das Event-Objekt. Ein mit addEventListener registrierter Handler bekommt das Event-Objekt automatisch. Eine generische Modulsteuerung würde diesen click-Handler auch nicht auf jedem Modul registrieren, sondern auf dem gemeinsamen Container aller Module. Wenn dieser click-Handler dann feststellt, dass ein Button gedrückt wurde der ein Modul ein/ausschaltet, sucht er in der Eltern-Hierarchie des Buttons das betreffende Modul-Div (welches bspw. an einer class erkennbar wäre) und führt dann die Aktivierung oder Deaktivierung durch. Eine Registrierung, eine Funktion, kein Schmutz im HTML. Eventuell wäre dann auch das section-Element eine gute Alternative zum div. _Rolf_ -- sumpsi - posui - clusi