Re: JQUERY extension to get event listeners seems to be limited

Well - that's disappointing.


On Thu, Aug 28, 2014 at 10:43 AM, Gunderson, Jon R <jongund@illinois.edu>
wrote:

>  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>
> 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
>
>
>
>
>