Re: Enumeration of EventListeners in DOM Level 3 Events

This is what we have needed so we could discuss how completely flawed 
the current proposal seems to be (to me).

What do you want to allow the user to listen to?  The binary addresses 
of handler routines?  That is all that the current API provides.  No 
clue about what kind of events the listener accepts or what type of 
action might be taken.

How do you plan to permit the user to invoke these?  Trial and error? 
 The API as proposed gives no clue about what types of events should be 
sent to the handlers it enumerates, which handlers were established by 
native DOM extensions versus by scripts, or which handlers might be 
capturing the events of the hierarchy?  

While the implementation is required to have all of this information, it 
seems useless to enumerate the listeners if the enumeration does not 
supply more information about the listeners.

One possible solution might be to augment listener registration and 
enumeration to supply a lot of additional information.  However, 
arguably, other approaches might be more simple for implementers, simple 
for users and less prone to abuse.

It is not necessary to enumerate listeners to fire an event of a 
particular type at a node.  If all you want to know is whether an event 
would be processed if fired at a particular node, this is a very hard 
way to get there.  In fact, it only answers the question if after 
producing this implementation the user goes up the tree looking for 
handlers that might be handling a particular type of event, since events 
can be captured or bubbled.  There are events, which are never user 
activated, such as mutation events, that should NEVER be manually fired, 
so having them in the list would be wrong.

I think that the questions the accessibility program should be able to 
ask is something like:

If I were to fire an event of type "Key up" on this node, would it be 
processed?

If the answer is true (and it may be due to either the current node or 
due to ancestors in the hierarchy) then the accessibility program may 
give the user the option of sending a key press with a particular key. 
 He probably doesn't want to add a dozen different menu uptions for the 
dozen different listeners registered for the same event.  That would 
break the assumptions of the program were it possible to deliver events 
without proper capturing, bubbling, preemption, etc.  

An accessibility program cannot generally fire event types that it does 
not know because it does not know what type of event to create or what 
type of parameters need to be filled in, so it seems reasonable to query 
for specific types.  If there were cases that you wanted to cover where 
there might be a simple generic factory for events which never have 
parameters (unlike mouse button events or key events, and I cannot think 
of a good one off the top of my head that would be appropriate to 
accessibility since non UI events shouldn't be fired in such a scenario 
anyway), you could make an enumeration function that enumerated the UI 
(user activated) event types that might be responded to.

Perhaps the best way to answer the question is via an event that the 
listeners respond to.   I would also suggest that while we are 
augmenting the APIs, we might also consider putting a hook for an 
additional semantic tag if this is a use case we believe in strongly enough.

Ray Whitmer
rayw@netscape.com

Jon Gunderson wrote:

> Philippe,
> Here are some possible use cases:
>
> 1. Someon with a visual impairments that uses assistive technologies 
> (AT) to render web resources through speech output (IBM Home Page 
> Reader, Freedom Scientific JAWS or GW-Micro Window Eyes) benefit, 
> since speech output ATs can use the DOM to enumerate the event 
> handlers and allow the user to listen to the list of possible user 
> activated events using only keyboard commands.  The user could choose 
> to trigger one of the event handlers from the list using keyboard 
> commands.  In this case it is important for the AT to be able to 
> figure out what user interface event handlers are associated with each 
> element in a resource.
>
> 2. Someone with a physical disability cannot use the standard pointing 
> device on a browser and uses a plug-in which allows them to to 
> identify and activate active elements in a web resource.  In this case 
> the plug-in needs to be able to find out which events are associated 
> with each element.
>
> 3. Someone with a cognitive disability does not want to have new 
> windows opened when they load a web resource.  By looking for "onLoad" 
> events a plug-in could be used to filter out or prompt the user before 
> opening any new windows. In this case the plug-in needs to be able to 
> find out if there are any on load events and then determine if any of 
> the scripts associated with the event open new windows.
>
> Are these the types of use cases you are looking for?
>
> Jon

Received on Wednesday, 12 December 2001 12:32:53 UTC