- From: Glenn Maynard <glenn@zewt.org>
- Date: Thu, 24 May 2012 22:27:48 -0500
- To: Jason Edward 今井 Parrott <parrott.jason@gmail.com>
- Cc: contact@xavierho.com, whatwg@whatwg.org
On Thu, May 24, 2012 at 8:34 PM, Xavier Ho <contact@xavierho.com> wrote:
> As far as the author could tell, this feature was never implemented due to
> a lack of a use-case. We have a use-case. Could someone share some
> thoughts on this?
>
The basic argument against it is that attaching an event listener that
doesn't do anything is currently guaranteed to be a complete no-op in all
cases. That is,
element.addEventListener("anything", function() { }, false);
is guaranteed to have no side-effects and to do nothing at all. Making
event listeners enumerable would remove that property.
I'm not personally concerned about that invariant, and I've wanted this in
the past myself (though honestly I don't recall off-hand what for).
On Thu, May 24, 2012 at 9:33 PM, Jason Edward 今井 Parrott <
parrott.jason@gmail.com> wrote:
> Personally, I wouldn't want some random library listening and
> possibly forcibly removing my event listeners.
> Some bad script could do this easily.
>
You always have to trust other scripts running in the same context. It
doesn't make sense to limit APIs by pretending that you don't.
On Thu, May 24, 2012 at 10:00 PM, Xavier Ho <contact@xavierho.com> wrote:
> The door's already open. You simply have to iterate through all the
> nodes, and call removeEventListener with all possible events.
>
Actually, you can't, since you can't remove an event without a reference to
the callback to pass to removeEventListener.
On Thu, May 24, 2012 at 10:07 PM, Xavier Ho <contact@xavierho.com> wrote:
> A very common use-case is to record a mouse click on a DOM element which
> may fire an event on the page. We want to capture clicks that actually
> triggered an event, does a HTTP request, and so on, but not meaningless
> clicks on an empty region.
>
> That said, there is no way of surely determining if a click is meaningful.
> We check if the DOM element clicked on is a button, a link (has href), has
> onclick attribute set, and so on. However, this will fail on sites that
> binds 'click' via 'addEventListener' on a strange element, like a <span> or
> a <em> tag.
>
This will also fail if the event handler is up the node tree. That's very
common with the event delegation pattern, where a capturing event listener
for is registered for a container object (even on the document). You have
no way of knowing whether it'll actually do anything for any particular
element. I don't think this is a realistic use case.
On Thu, May 24, 2012 at 10:25 PM, Mani <manips2002@gmail.com> wrote:
> )-@impact) u
>
(Alcohol?)
--
Glenn Maynard
Received on Friday, 25 May 2012 03:28:17 UTC