Re: Enumeration of EventListeners in DOM Level 3 Events

Al Gilman wrote:

>For those who are members and have the time, the PF contributions to DOM3
>requirements are available by starting at the letter of transmittal
>archived at
> <<http://lists.w3.org/Archives/Member/wai-liaison/2000Jun/0000.html>http:/
>/lists.w3.org/Archives/Member/wai-liaison/2000Jun/0000.html>.
>A cursory review suggests that it is not essential to resolving the narrow
>question Jon is trying to focus on.  
>
>On the agenda, as I understand it, here is a draft proposed resolution or
>clarification for DOM.  
>
>The user agent wants to know, for each event listener that is listening in the
>context of the document, what context it is listening in, and to access this
>relation in the inverse relationship:  for each context, what listeners are
>there for which that context is the proper context in which the listener is
>listening.
>
This seems quite confusing to me.  "What context it is listening in" 
needs some explanation, and all that about an inverse relationship -- is 
it needed?

I believe it is wrong for the user agent to know about or invoke 
specific listeners, unless they are semantic and designed to be invoked 
bypassing the normal event delivery mechanism of DOM.

Here would be my take:

The user agent needs to know, for any given node within the document, if 
there are listeners which would receive specific (UI) event types it is 
capable of generating targeted at that node so that the option to 
generate these events is only presented where there are listeners.

>Notes:
>
>+ Bubbling doesn't count.  If a listener with proper context at some ancestor
>node in the DOM element tree handles the event after bubbling, it is not
>included as associated with a descendant node.
>
I do not understand this rationale in terms of real use cases.  Do you 
wish to prevent the user from generating real events that a 
normally-accessing user would generate?  How about capturing listeners, 
that likewise may apply to nodes other than the one they are registered 
on?  No requirement is even listed here to detect capturing.

>+ All handlers count.  User agent wants to know all events that will be caught
>if thrown, not just those natively produced by the devices in use.  
>
It wants to only know about event types that it knows how to generate. 
 The others are irrelevant.

It also should not be permitted to distinguish between handlers that 
handle the same event type that should be invoked in concert, not 
individually.

>This may lead to throwing inadequately populated event data structures.  The
>handler may be asked to do error recovery, the user agent may gain type
>knowledge over the event and synthesize it by dialog or otherwise.  Those are
>content guidelines and assistive technology issues we probably don't have
>critical mass to answer at this point.  But there are feasible strategies, if
>the information about "what listeners pertain particularly to this node" were
>available.
>
In most common UI cases (such as keyboard and mouse) you cannot even 
consider ever getting it correctly populated without knowing what 
structure the event requires.  It will be difficult even to produce a 
good event once you completely understand the type.  Generating events 
to handlers of unknown types seems about as useful as jumping to random 
subroutines in the code hoping to find a useful result.

>Compare with the convention in server-side image maps where a (0,0) pointer
>value throws you into a pointer-free alternative dialog accessing an
>equivalent-facilitation service.
>
>[Please discuss if there are dynamically registered listeners, and how they
>fit
>into the scenario.]
>
>+ Event names would work, as menu identification of the handlers.  
>
Event types will do, if you can get the parameters filled in.  Method 
names are wrong at many levels, both because they do not exist in the 
DOM specification, and because it would imply that you are invoking 
listeners singly, when in fact they should only be invoked in concert, 
self-controlling propogation to related listeners.

>This is not what we want but if the event names as used in the source code
>were
>used as menu entries, suitably styled to be clear that they are not friendly
>names but pass-throughs of system names, the user would rapily learn what
>events this site uses for what kind of stuff and make reasonably effective
>choices as to what to do.  If they ever figured out that the context menu was
>worth looking at.  But that is our problem on the UA side as to how much to
>emphasize this stuff and configuration options that in fact profile how
>prominent this information is in the rendered content.
>
>That's my current estimate of what should and can be clarified.  Y'all can
>do a
>better job collectively, of course.
>
I suspect you would be disappointed at least 95 percent of the time if 
you actually tried this.  I believe it is wrong to try to coerce 
semantic meaning to handlers that are not semantic in nature.  They deal 
with hardware events.  The best you can do is simulate hardware events, 
not pretend they are semantic menu choices when they are not, whatever 
we may wish, until we take the time to design them as semantic things.

I have written lots of event-based handlers and never would these 
approaches have been useful.  Have you tried doing real-world application?  

Why is everyone so opposed to adding a level that is properly semantic? 
 That should be at the top of the list, rather than not appearing.  That 
is a convention that would be useful, rather than setting yourself up to 
condemn the creaters of pages using non-semantic events that, no 
surprise, do not behave well as menu choices.

Ray Whitmer
rayw@netscape.com

Received on Wednesday, 19 December 2001 18:36:38 UTC