- From: Gary Kacmarcik <notifications@github.com>
- Date: Fri, 17 Jan 2020 17:29:24 -0800
- To: w3c/uievents <uievents@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
Received on Saturday, 18 January 2020 01:29:26 UTC
The UIEvents glossary has the following definition: ``` : <dfn>candidate event handlers</dfn> : <dfn>candidate event listeners</dfn> :: The list of all <a>event listeners</a> that have been registered on the target object in their order of registration. When an event is about to be dispatched to a target object, the list of current listeners is captured before any event listeners are dispatched on the target. Listeners which are newly added after the event dispatch begins will not affect the order of listeners in the captured list, although listeners which are removed after dispatch begins will be removed. <p class="note"> Initially capturing the candidate event handlers and not allowing new listeners to be added prevents infinite loops of event listener dispatch on a given target object. </p> ``` This definition is not referenced anywhere. It also attempts to describe an implementation, so this should be incorporated into the algorithmic definition of how event handlers are implemented -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/w3c/uievents/issues/258
Received on Saturday, 18 January 2020 01:29:26 UTC