Re: Adding an interface to provide a list of listeners

I'm not sure the reply "this been discussed and rejected several times
before ... I would advise against reopening the discussion."  is terribly
helpful. To Shane's original question: which WG would be best to address
this with or to search down the history of the relevant discussions? Is
there a way to get access to those previous discussions or at least a
summary as to why?

Frankly, it does indeed seem like a worthwhile feature request. A google
search for "Get event listener" retrieves over a million results
https://www.google.com/search?q="get+event+listener"

I'm also personally aware of others' desire for something like
"getEventListener"
https://www.google.com/search?q=getEventListener

And that search turns up almost a quarter-of-a-million results. The top
results are quite relevant to this discussion and also demonstrate that
many people are looking for such a thing.  The fact is, the browsers
themselves already have this, but it isn't exposed in a way that devs can
get to.




On Thu, Jul 17, 2014 at 1:40 PM, Shane McCarron <shane@aptest.com> wrote:

> Oooh!  I was unaware that it had been discussed previously.  I will do a
> mailing list search.  If you have any pointers, I would love to see them.
>
>
> On Thu, Jul 17, 2014 at 11:51 AM, Ms2ger <ms2ger@gmail.com> wrote:
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Hi Shane,
>>
>>
>> On 07/17/2014 06:44 PM, Shane McCarron wrote:
>> > Hi!
>> >
>> > At a recent W3C PFWG meeting, the group (again) lamented the lack
>> > of a standard way to get a list of all the Event listeners (of a
>> > specific type, at a specific element, etc) in the DOM.
>> >
>> > We are happy to put together a proposal about this, with use cases,
>> > but we are not sure if we should target this at the DOM itself or
>> > at the DOM Events specification.
>> >
>> > Obviously we are not looking to rock the boat here w.r.t DOM4 or
>> > anything. We are just trying to figure out who we should be talking
>> > to about getting this included in some future specification.
>>
>> The DOM specification is a living standard, so don't worry about
>> rocking boats.
>>
>> However, this has been discussed and rejected several times before; is
>> there any new information that suggests a reasonable chance to
>> overturn those decisions? If not, I would advise against reopening the
>> discussion.
>>
>> HTH
>> Ms2ger
>>
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1.4.11 (GNU/Linux)
>> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>>
>> iQEcBAEBAgAGBQJTx/75AAoJEOXgvIL+s8n2Ok0IAI2u0Jwka4Dqyi0VcGQgvYRJ
>> cbAq8agq287hSyplUSJ6VmDvQbD4slDLRvVCuwS7hCAOSpoUsKIxgu4WNJhaUEhJ
>> hDtBGHnvL3JxD0jk3Jmf1Zn5lY98nms9cevpjWHWEjo8qrXbWrf4wfc5KeHeltWX
>> uKEk2Rm4ggO2RxZjQDMcT3l6OeVRXqbBf8czn9qW8oGJq6XFLN7/4t16Uwg0nkCA
>> YyUO5OO7qnpE7wC5Y3R6u131BWx4LmONfxufERtfhqRHgm4E/TlBb0stXqcukv1K
>> NI7CToBc2toRQ+f6Tu/n9GhqgdTSNbli27dACOaPiJv5nAv/xEZTGuriFt0TRko=
>> =tH6j
>> -----END PGP SIGNATURE-----
>>
>
>


-- 
Karl Groves
Senior Technical Lead Accessibility Software Consultant & Director of
Training
The Paciello Group
@karlgroves
Phone: +1 443-875-7343