Hallo AngularTool,
Der Dritte Parameter true ist offensichtlich vergleichbar mit dem event.done im C# oder VB.
Nein, wenn ich das eventdone richtig verstehe, entspricht das in etwa dem preventDefault Aufruf.
Ein Capturing-Eventhandler (addEventListener("...", handler, true)
) ist etwas Spezielles im DOM: Das Event sucht sich zunächst seinen Weg vom Root des DOM (also das Dokument) nach unten zum Event-Auslöser (capturing-Phase), wird dort geworfen (trigger) und blubbert dann zurück nach oben (bubbling-Phase). Das gibt's meines Wissens in .net so nicht, zumindest nicht die Capturing-Phase.
Wenn der Eventhandler auf dem Element registriert ist, auf dem das Event ausgelöst wird, ändert der 3. Parameter nichts. Trigger ist Trigger. Der Unterschied entsteht bei Registrierung auf Elternelementen im DOM.
Ist der 3. Parameter false, greift der Handler beim Bubbling. Das ist das vertraute Verhalten: Elternelemente können Events ihrer Kinder auch behandeln, aber die Kinder sind zuerst dran.
Ist der 3. Parameter true, greift der Handler vor dem Trigger. Das ist das Verhalten von überfürsorglichen Eltern: Alles erstmal begutachten bevor das Kind dran kommt.
Dabei haben die Eltern zwei Optionen: preventDefault - das sorgt dafür, dass der Browser das Event nicht mehr anfasst wenn es durch's JavaScript durchgereicht wurde. Und stopPropagation - das ist etwas anderes, aber genauso gemein: Das Weiterreichen des Events durch's JavaScript wird gestoppt. Das hindert den Browser aber nicht an seiner Default-Aktion.
D.h. ein preventDefault könnte - wenn Angular auf dem Element selbst lauscht, ggf. wirkungslos sein. Und zwar dann, wenn Angular die Tastendrücke aus irgendeinem schrägen Grund selbst verarbeitet. In dem Fall hilft dann nur noch das Fernhalten der leckeren Keydown-Kekse vom plärrenden Angular-Kleinkind, durch stopPropagation in der Capturing-Phase.
Rolf
sumpsi - posui - clusi