Re: Report on event listener investigation

First, let me say it's good to see this conversation back on the
technical track. We need that.

Second, let me clarify that my concern isn't so much protecting the
reputation of any individual, but rather the PF as a whole, and
particularly the process. While I would not want us to have to closely
gard what we say, words matter; and what we say here is archived.

So, for the sake of the record it's important to put on the record that
we're not seeking to get around anyone or any W3C group even as we try
to define precisely what we're looking for and how we think it might be
achieved. That's not a case of circumventing W3C process or groups,
though it might legitimately postpone particular conversations.


Janina

Shane McCarron writes:
> 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
> >
> >

-- 

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/

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