JQUERY extension to get event listeners seems to be limited

Shane,

Thanks for the reference and I looked at the code.

I fear that this extension will only work for event handlers that were added using JQuery.

While this is useful, it does not cover event handlers added to an element in other ways (e.g. addEventListener).

Jon


From: ahby@aptest.com [mailto:ahby@aptest.com] On Behalf Of Shane McCarron
Sent: Thursday, August 28, 2014 8:56 AM
To: Gunderson, Jon R
Cc: James Craig; Janina Sajka; W3C WAI Protocols & Formats
Subject: Re: Report on event listener investigation

That's possible.  I didn't dig into it.  Here is one that I know of: https://github.com/alvinteh/geteventlisteners


On Thu, Aug 28, 2014 at 8:53 AM, Gunderson, Jon R <jongund@illinois.edu<mailto:jongund@illinois.edu>> wrote:
Shane,

It looks like the jquery feature has been deprecated, or at least I could not find it in the latest release.

Do you have a reference?

Here is at least one discussion of the problems in jquery 1.9:
http://stackoverflow.com/questions/2518421/jquery-find-events-handlers-registered-with-an-object


Even if it does work, it may only provide information on the events added to the DOM using jquery.

Jon


From: ahby@aptest.com<mailto:ahby@aptest.com> [mailto:ahby@aptest.com<mailto:ahby@aptest.com>] On Behalf Of Shane McCarron
Sent: Thursday, August 28, 2014 8:10 AM
To: James Craig
Cc: Janina Sajka; W3C WAI Protocols & Formats
Subject: Re: Report on event listener investigation

Goodness sake.  You walk away from your computer for a few hours.....

James, you will find it way more difficult to irritate me than by correctly using an English word to characterize my proposal.  For the avoidance of doubt, I did not read your initial response nor any of your subsequent communications as anything other than your honest belief that developing an extension spec is a bad idea.

Janina, thanks for jumping in when you thought I was being maligned.  It was kind if you.  But really, I can take care of myself and my skin is pretty thick after ~30 years in standards ;-)

Now, as to the substance: Yes, I presented alternatives that included preparing an extension specification for the DOM.  I did that because 1) it was clear there was existing and possibly entrenched opposition in the DOM community, and 2) it was my impression that the only use cases we had for this feature were A11Y related.

James, you know more about the people involved and the use cases than I do.  If there are non-A11Y use cases, or if there is a path forward that does not require us to write yet another specification, then I am all for it.  It's not like we don't all have enough work to do already!

Finally, I will remind everyone that one of the things I mentioned in the call is that there already exists a jQuery extension that implements a common interface to expose event listeners.  I know that jQuery is not ubiquitous, nor is it native.  But if the problem we are trying to solve is to help with testing of our specs and conformance to our specs, relying upon jQuery is not the worst answer for the nonce.

Let's all settle down.  Let's gather use cases.  Let's find a path forward.  Or let's agree that we don't really need this.  And finally, remember that in the end all of us have the same macro agenda.  We are ensuring that the web (and other web-like devices) is accessible for everyone. It requires all of us working together to make that happen.


On Thu, Aug 28, 2014 at 3:32 AM, James Craig <jcraig@apple.com<mailto:jcraig@apple.com>> wrote:
Janina,

I was involved in some of the prior conversations. As Shane noted at the start of this thread, I suggested the EventTarget.listeners idea and mentioned that it be brought to the HTML or WebApps working groups for consideration. In response to Shane's original email, I recommended that PF *not* choose one of the paths listed: developing a general DOM extension outside of those groups would be futile and could result in marginalization of other WAI efforts like ARIA.

I'm not sure how we got to this point. I'm fairly certain Shane didn't take my use of the word "circumvent" to be inflammatory or an insinuation of malice, but I'm sorry you feel it was.

James


> On Aug 27, 2014, at 2:40 PM, Janina Sajka <janina@rednote.net<mailto:janina@rednote.net>> wrote:
>
> I have no idea who you're thinking of when you speak of "avoiding DOM
> groups." The W3C DOM4 spec is a product of the HTML-WG. The HTML-WG
> provides several paths for spec development, so considering which to
> choose (and why) is a strategic consideration. It would, in fact, be
> irresponsible not to consider the relative merits of the several paths
> available.
>
> I believe we all understand that, regardless of the path chosen from
> among available paths, passage to Recommendation status still goes
> through the HTML-WG.
>
> But, you have clarified that you did not use the word in haste. I'm
> sorry you felt it necessary to do so, and to reinforce it. I find it  inflamatory.
>
> I also find the suggestion that our concerns might not be a11y specific
> inflamatory and without the slightest shred of evidence.
>
> Since you do not customarily attend the regular PF weekly telecon, let
> me advise you that looking "into the reasons a listeners API was
> dismissed previously, and critically question whether another attempt is
> worthwhile" is precisely what we are doing. The topic will be back on
> the PF and HTML-A11Y agendas in September.
>
> I believe it would be far more helpful for you to get involved in the
> conversation. If, what your actually saying, is that you believe we need
> to battle with entrenched viewpoints before creating a documented
> approach, you could certainly say that without casting aspirtions on
> motives.
>
> Janina
>
>
>
>
> James Craig writes:
>> Thread starts here:
>> http://lists.w3.org/Archives/Public/public-pfwg/2014Aug/0090.html

>>
>>> James Craig writes:
>>>> On Aug 27, 2014, at 5:44 AM, Shane McCarron <shane@aptest.com<mailto:shane@aptest.com>> wrote:
>>>>
>>>>> Alternately, we could run the proposal through the HTML working group's DOM team.  There is clearly some opposition to this in the community, and we might run into that opposition harder there than if we just did it ourselves.
>>>>
>>>> I do not recommend PFWG circumventing the DOM groups on any issue that is not accessibility-specific. Instead, it’d be better to look into the reasons a listeners API was dismissed previously, and critically question whether another attempt is worthwhile.
>>
>>
>> On Aug 27, 2014, at 11:02 AM, Janina Sajka <janina@rednote.net<mailto:janina@rednote.net>> wrote:
>>
>>> I don't see any proposal to circumvent anything or anyone. Your use of
>>> that term is unfortunate, imo, and we should recognize this up front.
>>> I'm sure it was simply written in haste.
>>>
>>> I see Shane's email discussing various documented, legitimate
>>> approaches. Extension specs are one such approach agreed by consensus of
>>> the HTML-WG as part of Plan 2014. It's not circumvention to suggest PF
>>> might want to propose moving forward via an extension specification.
>>> Clearly, also by agreement with the HTML-WG, we would do so via the
>>> HTML-A11Y TF, as indeed we would were we to seek to impact the dom spec
>>> directly. In fact, starting with an extension is one path blessed in
>>> Plan 2014 for affecting the primary specification. Keeping the extension
>>> spec spearate is an independent process decision that the HTML-WG would
>>> still need to accept.
>>>
>>> So, this is discussion of available options, not a call to
>>> circumvention.
>>
>> The term circumvent just means to "find a way around an obstacle." I think that usage is fair and accurate in this context given that Shane said:
>>
>>>>> There is clearly some opposition to [a listeners API] in the community, and we might run into that opposition harder [if we ran the proposal past the DOM team] than if we just did it ourselves.
>>
>>>>
>>>> I do not recommend PFWG circumventing the DOM groups on any issue that is not accessibility-specific. Instead, it’d be better to look into the reasons a listeners API was dismissed previously, and critically question whether another attempt is worthwhile.
>>
>> Janina, you may be referring to the archaic definition of circumvent which means "to deceive." I was not ascribing any intention of malice or deception to Shane's comment. My comment was merely meant to convey that developing a new DOM API to expose event listeners on an element node is well outside the charter of both the PFWG and HTML-A11y-TF, primarily because it is not an accessibility-critical or accessibility-specific need. I think it would be both a technical and strategic mistake for either group to do develop on its own.
>>
>> It's great that Shane has researched and listed options. I think a listeners interface would very useful, but I don't think PFWG or HTML-A11Y-TF should develop it.
>>
>> James
>>
>
> --
>
> Janina Sajka, Phone:  +1.443.300.2200<tel:%2B1.443.300.2200>
>                       sip:janina@asterisk.rednote.net<mailto:sip%3Ajanina@asterisk.rednote.net>
>               Email:  janina@rednote.net<mailto:janina@rednote.net>
>
> Linux Foundation Fellow
> Executive Chair, Accessibility Workgroup:     http://a11y.org

>
> The World Wide Web Consortium (W3C), Web Accessibility Initiative (WAI)
> Chair,        Protocols & Formats     http://www.w3.org/wai/pf

>       Indie UI                        http://www.w3.org/WAI/IndieUI/

>
>
--
Indifference towards people and
the reality in which they live
is actually the one and only
cardinal sin in design.
                — Dieter Rams