Witam,

Jaka jest praktyczna różnica w stosowaniu:

addEventListener(event, handler, true);

vs

addEventListener(event, handler, false);

Zauważyłem, że czasem w przykładach podkreślane jest aby ustawić ten
ostatni parametr na konkretną wartość. Jednakże jakie ma to praktyczne
znaczenie? Nie wiem.

--
Pozdrawiam,
Marek

do góry

On 2015-02-12 13:14, Marek wrote:
> Witam,
>
> Jaka jest praktyczna różnica w stosowaniu:
>
> addEventListener(event, handler, true);
>
> vs
>
> addEventListener(event, handler, false);
>
> Zauważyłem, że czasem w przykładach podkreślane jest aby ustawić ten
> ostatni parametr na konkretną wartość. Jednakże jakie ma to praktyczne
> znaczenie? Nie wiem.

Osobiście nigdy nie miałem potrzeby użycia "captures" w wersji "true".

Znalazłem ciekawy wątek wokół "captures":
http://stackoverflow.com/questions/7398290/unable-to
-understand-usecapture-attribute-in-addeventlistener

--
Cezary Tomczyk
http://www.ctomczyk.pl/

do góry

W dniu 2015-02-12 o 17:43, Cezary Tomczyk pisze:

> Osobiście nigdy nie miałem potrzeby użycia "captures" w wersji
> "true".

No właśnie w tym rzecz. Sam nie znalazłem jeszcze praktycznego
wykorzystania. Zwykle interesuje nas zdarzenie na danym elemencie.
Odwrócona kolejność taka, że najpierw odezwie się document gdy klikniemy
w nim button jest średnio przydatna. Też nie bardzo znajduję potrzebę
korzystania z tego mechanizmu i stąd pytanie

>
> Znalazłem ciekawy wątek wokół "captures":
> http://stackoverflow.com/questions/7398290/unable-to
-understand-usecapture-attribute-in-addeventlistener
>

A tak, dziękuję. Widziałem diagram na W3C i fajnie, że jest tu również
JS do przetrenowania. Co gorsze, pobawiłem się tym i ...kolejna, tym
razem niejasność powstała. Zaskoczyło mnie działanie stopPropagation()

w przykładzie z w/w wątku: http://jsfiddle.net/sc5Xa/2/

Odkomentowałem przy "parent capture". Tak jak się spodziewałem - żadne
kolejne zdarzenie nie zaszło. Postanowiłem więc przetestować drugie
zdarzenie "children capture" i teraz tam zatrzymałem propagację. Ze
zdziwieniem ... zablokowałem w ten sposób jedynie "parent bubble".
Dlaczego "children bubble" nie zostało odcięte przez stopPropagation() w
"children capture"???


--
Pozdrawiam,
Marek

do góry

On 2015-02-12 22:10, Marek wrote:
> W dniu 2015-02-12 o 17:43, Cezary Tomczyk pisze:
>
>> Osobiście nigdy nie miałem potrzeby użycia "captures" w wersji
>> "true".
>
> No właśnie w tym rzecz. Sam nie znalazłem jeszcze praktycznego
> wykorzystania. Zwykle interesuje nas zdarzenie na danym elemencie.
> Odwrócona kolejność taka, że najpierw odezwie się document gdy klikniemy
> w nim button jest średnio przydatna. Też nie bardzo znajduję potrzebę
> korzystania z tego mechanizmu i stąd pytanie

Wydaje mi się, że to pozostałość historyczna kiedy jeszcze Netscape i IE
miały różne koncepcje event delegation. Tutaj
http://www.nczonline.net/blog/2009/06/30/event-deleg
ation-in-javascript/
jest to ładnie opisane.

>> Znalazłem ciekawy wątek wokół "captures":
>> http://stackoverflow.com/questions/7398290/unable-to
-understand-usecapture-attribute-in-addeventlistener
>>
>>
>
> A tak, dziękuję. Widziałem diagram na W3C i fajnie, że jest tu również
> JS do przetrenowania. Co gorsze, pobawiłem się tym i ...kolejna, tym
> razem niejasność powstała. Zaskoczyło mnie działanie stopPropagation()
>
> w przykładzie z w/w wątku: http://jsfiddle.net/sc5Xa/2/
>
> Odkomentowałem przy "parent capture". Tak jak się spodziewałem - żadne
> kolejne zdarzenie nie zaszło. Postanowiłem więc przetestować drugie
> zdarzenie "children capture" i teraz tam zatrzymałem propagację. Ze
> zdziwieniem ... zablokowałem w ten sposób jedynie "parent bubble".
> Dlaczego "children bubble" nie zostało odcięte przez stopPropagation() w
> "children capture"???

Klucz to zagadaki jest tutaj
http://www.w3.org/TR/DOM-Level-3-Events/#event-flow

+ https://msdn.microsoft.com/en-us/library/ie/ff975245
(v=vs.85).aspx

"Events are handled in two phases: capturing and bubbling. During the
capturing phase, events are dispatched to parent objects before they are
dispatched to event targets that are lower in the object hierarchy.
During the bubbling phase, events are dispatched to target elements
first and then to parent elements."

--
Cezary Tomczyk
http://www.ctomczyk.pl/

do góry

W dniu 2015-02-12 o 23:26, Cezary Tomczyk pisze:
>
> Klucz to zagadaki jest tutaj
> http://www.w3.org/TR/DOM-Level-3-Events/#event-flow
>
> + https://msdn.microsoft.com/en-us/library/ie/ff975245
(v=vs.85).aspx
>
> "Events are handled in two phases: capturing and bubbling. During the
> capturing phase, events are dispatched to parent objects before they are
> dispatched to event targets that are lower in the object hierarchy.
> During the bubbling phase, events are dispatched to target elements
> first and then to parent elements."
>

No ale z tego nie wynika jasno, że stopPropagation() w pewnych
okolicznościach nie działa. Posługując się diagramem z W3C, gdy np.
klikamy na <td>, zdarzenie zaczyna wędrować najpierw w capturing phase
począwszy od window, aż do targeta a potem z powrotem. Wyobrażałem
sobie, że jeśli przerwiemy ten przebieg gdziekolwiek w capturing phase,
to następny w kolejce element nie dostanie informacji o tym, że takie
zdarzenie miało miejsce. W opisie nie jest napisane, że stoPropadation()
zadziała z opóźnieniem.

--
Pozdrawiam,
Marek

do góry

W dniu 2015-02-12 o 13:14, Marek pisze:
> Witam,
>
> Jaka jest praktyczna różnica w stosowaniu:
>
> addEventListener(event, handler, true);

Praktyczna jest taka, ze IE<9 nie umie tak.

Dlatego powszechna praktyka jest rejestrowanie zdarzen z wykorzystaniem
fazy bubblingu addEventListener(event, handler, false). Aktualnie trzeci
parametr w addEventListener jest opcjonalny i domyslnie false, a
skladnie z 3 parametrami stosuje sie dla zgodnosci wstecz.


--
NotBear

do góry

W dniu 2015-02-12 o 22:10, Marek pisze:
> Dlaczego "children bubble" nie zostało odcięte przez stopPropagation() w
> "children capture"???

Bo juz jestes w children, wiec jego zdarzenia zostana obsluzone.
Zwroc tez uwage (zamien kolejnosc w kodzie), ze w najglebszym elemencie
nie ma znaczenia podawanie fazy, bo i tak wszystkie zdarzenia sie
wykonaja w kolejnosci dodawania.

StopPropagation jedynie nie wypuscilo zdarzenia dalej (w tym przypadku
do parenta). Aby to bylo dobrze widoczne warto dolozyc grandchild:
http://jsfiddle.net/erw6gwdk/ i potestowac blokowanie w elemencie child.

--
NotBear

do góry

W dniu 2015-02-13 o 14:37, NotBear pisze:
> StopPropagation jedynie nie wypuscilo zdarzenia dalej (w tym przypadku
> do parenta). Aby to bylo dobrze widoczne warto dolozyc grandchild:
> http://jsfiddle.net/erw6gwdk/ i potestowac blokowanie w elemencie child.
>

Wlasciwy link: http://jsfiddle.net/erw6gwdk/1/

--
NotBear

do góry

W dniu 2015-02-13 o 14:37, NotBear pisze:

> StopPropagation jedynie nie wypuscilo zdarzenia dalej (w tym przypadku
> do parenta).

Wszystko jasne. Czyli zatrzymanie propagacji nie obejmuje obiektu, który
tego dokonał a jedynie w/g kolejności następne obiekty. To mnie zmyliło
faktycznie. Dzięki :-)


--
Pozdrawiam,
Marek

do góry

W dniu 2015-02-13 o 14:23, NotBear pisze:

>
> Praktyczna jest taka, ze IE<9 nie umie tak.
>

Czyli nawiązanie do (pre)historii i nic praktycznego...


--
Pozdrawiam,
Marek

do góry