🚀 go-pugleaf

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/

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

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-delegation-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/

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

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

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

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

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

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