Re: Report on event listener investigation

Gah. It'd be nice if plugin authors supplied tests!

Generally though, its less desirable to monkey patch this sort of
thing than it would be to have it be a native DOM method that's
accessible via a client application.

I've forked it and will try to write some unit tests to verify that it
satisfies the use cases Jon outlined. If nothing else it could be used
as a POC for attempting to define what should exist in the DOM
natively.

On Thu, Aug 28, 2014 at 9:55 AM, Shane McCarron <shane@aptest.com> wrote:
> 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>
> 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] 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> 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> 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> 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> 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
>> >                       sip:janina@asterisk.rednote.net
>> >               Email:  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
>>
>>
>
>



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

Received on Thursday, 28 August 2014 14:14:57 UTC