Re: Enumeration of EventListeners in DOM Level 3 Events

At 11:19 AM 2001-12-19 , Richard Schwerdtfeger wrote:
>Jon,
>
>I agree there is a communication problem. I have a concern that
>requirements submitted by the PF 1.5 years ago have not even been read by
>some DOM WG members. If there were problems then we could have used the
>time to address them.
>

AG::

A review of the process is always appropriate.  If I understand Jon's agenda,
it is not necessary to accomplish a review of the history to address what he
wants to discuss, which is to clarify what the user agent wants from the DOM,
in the particular area of the DOM node to event listener relation, in the
context of a scenario showing what the user agent would do for the user.

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.

All listeners for which [pardon my pseudoCode]
 thisNode.arcRole(listener) = listeningIn; 
 thisNode = listeningIn(listener).

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.

+ 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.  

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.

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.  

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.


>Rich
>
>
>Rich Schwerdtfeger
>Senior Technical Staff Member
>IBM Accessibility Center
>Research Division
>EMail/web: schwer@us.ibm.com
>
>"Two roads diverged in a wood, and I -
>I took the one less traveled by, and that has made all the difference.",
>Frost
>
>
>
>                                                                           
                   
>                    Jon
Gunderson                                                             
>                    <jongund@uiuc.       To:     Philippe Le Hegaret
<plh@w3.org>, Richard    
>                    edu>                 
Schwerdtfeger/Austin/IBM@IBMUS                      
>                                         cc:     Ray Whitmer
<rayw@netscape.com>, "Ian B.     
>                    12/18/2001            Jacobs" <ij@w3.org>,
w3c-wai-ua@w3.org,             
>                    11:50 AM             
www-dom@w3.org                                      
>                                         Subject:     Re: Enumeration of
EventListeners in    
>                                          DOM Level 3
Events                                  
>                                                                           
                   
>                                                                           
                   
>                                                                           
                   
>
>
>
>I think it is clear there needs to be better communication better UA/PF/DOM
>
>on this issue.  To make the W3C process work we need to focus on making
>sure we all understand the need and possible solutions.  The solutions can
>come from past techniques or from new ideas, but let's use this discussion
>to point out the technical deficiencies or capabilities of proposed
>solutions in meeting the need.  If there were proposed specifications from
>a year ago that are not apart of the current specification, it would be
>more useful to discuss how the current specification differs from the
>proposed specification and/or how the current specification could be
>modified.
>
>Jon
>
>
>At 12:28 PM 12/18/2001 -0500, Philippe Le Hegaret wrote:
>>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?
>>
>>Ray's comment is a valid comment from the DOM Working Group. We
>participated
>>in the WAI UA call last Friday to better understand the situation [1]. The
>DOM
>>Working Group does not reject the action item from the March meeting. We
>are
>>still committed to address it but we do not believe that the current
>solution
>>proposed in the DOM Level 3 Events draft in the right one. If you are not
>>satisfied with the outcome of the teleconference, I suggest you to talk to
>>the WAI UA/PF representatives and review the list of use cases [2]. For
>the
>>moment, we will continue to work with the WAI UA, WAI PF, and other WGs on
>
>>events
>>to find "a way to get the list of registered event handlers". btw, this is
>
>>a UA
>>requirement, not a PF one since it came up at the WAI UA/DOM joint f2f
>>meeting.
>>
>>Regards,
>>Philippe
>>
>>[1]
<http://lists.w3.org/Archives/Public/w3c-wai-ua/2001OctDec/0105.html>http://
lists.w3.org/Archives/Public/w3c-wai-ua/2001OctDec/0105.html
>>[2]
<http://lists.w3.org/Archives/Public/www-dom/2001OctDec/0151.html>http://lis
ts.w3.org/Archives/Public/www-dom/2001OctDec/0151.html
>
>Jon Gunderson, Ph.D., ATP
>Coordinator of Assistive Communication and Information Technology
>Division of Rehabilitation - Education Services
>MC-574
>College of Applied Life Studies
>University of Illinois at Urbana/Champaign
>1207 S. Oak Street, Champaign, IL  61820
>
>Voice: (217) 244-5870
>Fax: (217) 333-0248
>
>E-mail: jongund@uiuc.edu
>
>WWW: <http://www.staff.uiuc.edu/~jongund>http://www.staff.uiuc.edu/~jongund
>WWW: <http://www.w3.org/wai/ua>http://www.w3.org/wai/ua
>

Received on Wednesday, 19 December 2001 13:08:19 UTC