Re: Report on event listener investigation

Thanks, James. I appreciate this mail from you very much. I think the
air is cleared of misunderstandings among us, and that makes me glad.


Janina

James Craig writes:
> On Aug 28, 2014, at 7:56 AM, Janina Sajka <janina@rednote.net> wrote:
> 
> > …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
> > guard what we say, words matter; and what we say here is archived.
> 
> I am sorry, and apologize, if you or anyone else found what I wrote offensive. It was not intended to be so. I am also interested in protecting the reputation of the PF Working Group. I believe its work is valuable. Otherwise, I would not be a member.
> 
> > 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.
> 
> As you said earlier, we are discussing options:
> 
> >>>>> 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.
> 
> One of the options listed was to have PF or HTML-A11Y-TF develop an extension specification for a new property on the EventTarget interface, exposing the currently registered event listeners. My feeling is that this is not a good direction to follow: not because it's procedurally inappropriate (it is appropriate procedurally, we are clearly allowed to develop extension specifications), but for two other reasons:
> 
> * DOM specification development really needs the expertise of people who do 
>   that; this is a specialized area with interesting dependencies and cross-
>   links. There ARE areas where extension specifications make sense — where 
>   what they specify is essentially independent, but this is not one of those 
>   cases.
> 
> * Significant, and almost certainly predominant, use of a listeners extension
>   to the EventTarget interface, if it is specified, would be for non-
>   accessibility reasons and use cases. This means that an accessibility group 
>   would either have to gather and understand and consider all these use-cases
>   outside our area, or we would risk getting it wrong for some other 
>   constituencies.
> 
> The other specialist considerations for this interface that lie outside the expertise of PF might include (and I say might, because I am not myself a DOM designer, and I just see the possibility of issues or questions in these areas):
> 
>   a. potential for abuse,
>   b. security,
>   c. user privacy,
>   d. rendering engine performance, and
>   e. interaction and overlap with other DOM interfaces.
> 
> I'm offering personal opinions on the options here; my feeling is that pursuing this option would not work well for the overall web and W3C community, for the reasons above. I hope this helps to move the discussion along.
> 
> Cheers,
> 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 Friday, 29 August 2014 01:36:53 UTC