W3C home > Mailing lists > Public > public-webapi@w3.org > March 2006

Re: in defence of listener discovery (ISSUE-32, ACTION-84)

From: Jonas Sicking <jonas@sicking.cc>
Date: Thu, 23 Mar 2006 15:31:22 -0800
Message-ID: <44232FCA.7010000@sicking.cc>
To: Al Gilman <Alfred.S.Gilman@IEEE.org>
Cc: WebAPI WG <public-webapi@w3.org>, wai-liaison@w3.org

Al Gilman wrote:
> Question:
> Why does the accessibility community want the hasEventListener?
> Actually, as I read the current Note, it is willTrigger and not 
> hasEventListener
> that is the key method to enable the functionality needed for UI 
> adaptablility.

Actually, my main question is not why the these functions are needed, 
but why they are needed in the DOM API. I'm thinking from the 
perspective of a browser here, so let me know if these APIs are intended 
for UAs other then browsers.

Is the accessibility code intended to be run by javascript living in the 
webpage? As in, is the author of the webpage is supposed use these APIs? 
Or are they intended to be used by authors of accessibility tools like 
screen reader plugins? Or are they intended for the browser itself?

If they are intended for the web author:
What is the author supposed to do with this information? And wouldn't 
the author know this anyway since he/she wrote the code that registered 
the EventListeners in the first place. Seems like the author could in 
that case simply use a utility function that not only registered the 
listener but also remembered which listeners are registered and provide 
the same functionality as the proposed APIs.

Like Jim pointed out, you could even override addEventListener so that 
this would be transparent.

If they are intended for browser authors:
Since the browser implements the DOM it has access to all available 
information, even if it is not accessible through public DOM APIs. In 
fact, browsers often use internal APIs rather then DOM APIs since they 
can be optimized more heavily then the generic DOM APIs.

In general I'm against the idea of adding DOM APIs intended for the DOM 
implementation to use. The end result is often that the implementation 
doesn't use them anyway and ends up having to implement both internal 
APIs as well as the DOM APIs.

If they are intended for plugin authors:
Plugin authors generally use other APIs then DOM APIs. It would in this 
case make more sense to add these functions to the NPAPI and ActiveX 
APIs used by the various browsers out there.

So basically, my question is: Who is the intended audience of these 
APIs, and how is it expected that that audience use them.

Best Regards,
/ Jonas Sicking
Received on Thursday, 23 March 2006 23:33:44 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:16:20 UTC