Re: Report on event listener investigation

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/

Received on Wednesday, 27 August 2014 21:41:17 UTC