Re: Enumeration of EventListeners in DOM Level 3 Events

I have removed www-dom because I believe you have referred to 
discussions that are not public.  I added instead w3c-dom-ig.

Adding the event type enumeration only fixes a small part of the fact 
that it is broken.  There is no justification to ignore the other issues 
that have been repeated here.  Enumeration of types leads to broken 
thinking about listeners, and enumeration of listeners is even worse 
because there are already methods for properly dispatching an event of 
any given type at a given node and the only reason to enumerate them 
would be to invoke them improperly.

The place to get a list of possible types is from a specification, not 
from an enumeration, because you cannot dispatch previously-unknown 
types.  The proper way to dispatch events to the listener is to call the 
dispatch function.  And best way to know whether a listener responding 
to a specific type that you know and care about is present would be to 
ask specifically.  Enumerating the types at a single node doesn't tell 
you the listeners that will respond to events on that node, and gives 
you more information that is useless and likely to be harmful.

In all of this, there is no real justification for enumeration of types 
or listeners.  The use cases we have seen only require knowing whether 
handlers will receive specific events of known types of a given node 
(notice that I did not say at a given node, because that is not the same 
as of, which is another part of what is broken with the enumeration). 
 Since DOM Level 2, you can fire an event, and not in the haphazard way 
that is most likely to result if someone is manually invoking listeners, 
that will break the assumptions of the script writer about delivery of 
events according to the specification.

Richard Schwerdtfeger wrote:

>Ray,
>
>It appears that you are complaining about issues that are a direct result
>of the DOM working group including only part of the requirements I had
>placed on you for PF. What would you have me say? Stop shooting yourself
>with the arrows?
>
We had no problem with our requirements -- only with those represented 
as coming to us "from WAI", which are broken and do not support use cases.

I was told that the requirement that this feature was based upon was 
"let us enumerate listeners".  If you had emphasized "let us enumerate 
listener types" instead of "let us enumerate listeners", I suspect that 
we would have been happier to do that instead.  But either enumeration 
is broken when dictated as a requirement, because it ignores the real 
problems that needs to be solved and insists on a broken solution that 
doesn't even solve the problem at hand.

>>How does the application construct the proper event, by trial and error?
>>
>
>First, an authoring tool ought be able to do this. How might you expect a
>person to create an application without this capability? I also believe
>this may be implementation dependent.
>
Applications can only do this about event types they know about. 
 Enumeration of event types you do not know about is useless at best. 
 The ability to deal with a specific event type comes from an 
application following a specification.  Events which are implementation 
dependent without subscribing to a standard specification cannot be 
properly invoked by an application.  This is the fallacy of the thinking 
(that lead to the current situation) that you can blindly:

1.  enumerate the events
2.  list them on the menu
3.  invoke them from the menu

A far more real description would be:

1.  Identify certain user-based event types that certain classes of 
users cannot generate due to an alternative UI -- this has nothing to do 
yet with what has been registered.
2.  Carefully construct handling with alternate user interface for these 
types.  For example, a keystroke requires a code, a mouse requires a 
position and button state, etc.
3.  Permit the user to fire the carefully constructed events at the node 
in question.  Presumably requiring the user to numerically speak the key 
codes or mouse coordinates is a bad thing so there is a significant 
amount of effort to design a suitable alternative UI for firing many UI 
events.

The ability to do this is already completely available from DOM as it 
exists today.  All that is missing is

4.  Permitting these known specific event types to be omitted from the 
accessibility menu if there are no known listeners.  This neither 
requires nor suggests as a good solution enumeration of listeners, which 
there is no reason for, nor even enumeration of event types registered 
on a particular node.

>>What if the user chooses to invoke functions that should never be user
>>accessible, such as mutation events.
>>
>
>If you new the "type" of event you could selectively pick those which you
>fire. So what might happen if the mutation event was fired. ... probably
>nothing since the application would look to see what changed.
>
It is quite possible to send bad info and crash the application by 
giving it a previously-impossible situation, such as a null reference. 
 Willy-nilly invoking of handlers is not a good idea.  Any application 
which permits events to be erroneously fired is badly broken.  The 
application discussed here should only fire well-designed UI events, and 
enumerating lots of handlers it is clueless about is worse than useless.

Far better to ask a question, "are events of this specific type that I 
can generate well handled by a listener"?

>>How does the DOM Level 3 script know which event type definition applies
>>to the function, or which listeners must only be invoked in concert?
>>
>
>Another requirement that I had placed on DOM 3 for PF was to be able to
>have a description for each event. Currently, there is no mechanism in
>script to store a description of the event function executed so I when I
>met with PF for DOM 3 I had asked that the function name be stored. Lauren
>Wood thought this was not an unreasonable request at the time.
>
That's easy.  The function name is "handleEvent".  Look at the IDL.  You 
can make it a constant in your program, but it solves no problems. 
 Javascript implementations may make a wrapper outside of DOM of an 
arbitrarily-named function, but according to the DOM specification, the 
IDL fixes the name, and if you give Netscape an object, as the 
specification states and do not rely on this wrappering, it must be 
named handleEvent.

Also, it is flawed to present this name as a menu item to a user, 
because it implies that he can invoke the single handler individually, 
and it would be broken to do so, because handlers of a specific type 
work in concert.  One key handler may handle the letter "Q" to quit a 
specific mode.  The parent may handle all other keystrokes.  The only 
way to properly invoke the key handlers is together.  Even if it says 
"QuitState", it will not quit the state of the program unless it gets 
the Q and the proper way to fire a keystroke is at all applicable 
handlers until one cancels.  They are likely to rely on each other.

>These are all fine questions. The bottom line here is that the DOM working
>group only implemented part of the requirements. There is not much I can do
>about that except that that if DOM 3 needs to be an interim step to where
>we want to go then lets take it. I would love to have had the DOM working
>group include all the PF requirements but you are going to do what you are
>going to do.
>
These PF requirements are very poor and broken.  Hacks at best that 
won't work well a majority of the time.  We have talked to you for quite 
some time about your specifying  semantic events (that would make sense 
to enumerate and would be able to automatically appear on a menu, etc.) 
but you haven't done them, and "you are going to do what you are going 
to do".  This is much better than the hacks you are pursuing today, IMO.

The bottom line is several of the DOM group objected to the requirements 
-- as we did at the time -- because they said "enumerate listeners", 
which was obviously broken and had already been repeatedly rejected for 
similar reasons.  But it kept getting left in because it came from WAI, 
ignoring a discussion of the merits.  It needs to be fixed or 
eliminated.  If the requirements had had anything to do with the real 
accessibility use cases and had acknowledged the existing state and 
design of DOM, then we would be a lot further along today.

>What the DOM WG needed to do is:
>
>   Enumerate all events by type
>   For each event provide a description for future script writers to be
>   able to store a text description. For now DOM implementers should store
>   the function name here. (We had discussed this when I met at the face to
>   face)
>   Allow the user to be able to fire each event based on the information
>   received from the type and description.
>
An event is something that is delivered to a listener.  There are never 
any events attached to a node to enumerate.

Enumerating listeners is a very broken approach, because the code itself 
is the most concise description of what a handler will do.  As much as 
you would like them to be semantic, they are not.  Just adding a 
semantic description does not help in the least.  The function name is a 
constant.  And if you had access to it, it would be improper at several 
levels, as I have explained, to present it to the user.  The DOM 
implementation knows no function name, because according to the DOM 
specification, the name of the handler is always the same.  Even if it 
did, it would be completely wrong to present it to the user except in a 
few limited circumstances that you have not advocated a way of detecting.

I will strongly oppose the ability to individually fire events -- not in 
concert as the DOM specification requires -- because it breaks 
compatibility with DOM level 2 and breaks the assumptions people make 
when they write scripts -- that they work in concert.  If you want that 
type of model,design it.  Don't blame other non-semantic systems for not 
being semantic.

You can keep trying to shift blame, but the problem is that the WAI 
group has not produced semantic events, which has been ignored for quite 
some time.  Then, the accessibility guidelines can require that for 
accessibility purposes, non-semantic events should restrict themselves 
to dealing with the UI and then invoking semantic events.

>What WCAG needs to do is:
>
>   Define industry standard techniques for storing functional descriptions
>   in web content.
>
This is entirely wrong.  Even if you could store a functional 
description of what a particular mouse click handler would do, it would 
be nearly impossible for an accessibility provider to intelligently use 
a description of what many, and likely most, typical UI event handlers do.

You need to simplify, and use semantic events to establish a level that 
can be intelligently invoked from alternative UIs.

>   Come up with standard descriptions for common functions.
>   Document a way for DOM implementers to retrieve them.
>   Work with standards bodies, like that for ECMA script, to hav them
>   accepted.
>
This is way more than you need to do, and the result is not as useful as 
simple semantic events.

>People working in accessibility have had to fight for every beach head they
>can get. If the DOM working group implements part of what we asked in level
>3 then it is easier to get the rest in 4.
>
What you are fighting for here is useless.  Start listening.  Hacking UI 
events will never be a good solution, no matter how you decorate them. 
 Especially as you begin adding new requirements on the script writer, 
why maintain the hackish approach when you can move towards a simple 
semantic design that will be easier for everyone.

As I have said, the ability to ask about the presence of a specific type 
of listener in the hierarchy of a particular node is something we could 
discuss, but you have a lot of broken ideas in this writeup to overcome, 
so don't blame us that you didn't do symantic events.  They are not that 
hard.

Ray Whitmer
rayw@netscape.com