Re: Enumeration of EventListeners in DOM Level 3 Events

Ray,

We can go back and forth on this and annoy the people on the list serve to
no end. Let's deal with this at the next telecon Ian is setting up.

When these messages first were sent you said you had not seen the PF DOM 3
requirements specificaiton. I am not sure if have had a chance to do so. If
not it would be good for you to read the DOM requirements specification
that the PF group sent in June 2000 before the next meeting. This should
help explain the things we were asking. For example, it is clear from the
last meeting that you had thought we wanted to enumerate each and every
event attached to an element. This was cleared up at the meeting.

If you need a link I would be happy to provide it to you.

Thanks,
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



                                                                                               
                    rayw@netscape.c                                                            
                    om (Ray               To:     Richard Schwerdtfeger/Austin/IBM@IBMUS       
                    Whitmer)              cc:     "Ian B. Jacobs" <ij@w3.org>, Philippe Le     
                    Sent by:               Hegaret <plh@w3.org>, www-dom@w3.org,               
                    w3c-wai-ua-requ        w3c-wai-ua@w3.org, w3c-wai-ua-request@w3.org        
                    est@w3.org            Subject:     Re: Enumeration of EventListeners in    
                                           DOM Level 3 Events                                  
                                                                                               
                    12/20/2001                                                                 
                    01:30 PM                                                                   
                                                                                               
                                                                                               



Richard Schwerdtfeger wrote:

>Ray,
>
>Again, I agree it would be nice to have semantic model for events. And I
>would like to get to where you want to go.
>
>Your solution does not deal with billions of lines of existing JavaScript
>code that plagues the disabled community today. I agree that for new XML
>based content and possibly new HTML content that you could do what you are
>suggesting. It will require extensive changes to ECMA script, the DOM,
>WCAG, authoring tools, etc.
>
Nor does yours, as I have explained.

I would lobby against the feature if it is dead weight that cannot work
because of the realities

It would not be too hard for the advocates of the hack to put together a
working model of this type of interaction on an open sourced browser,
such as mozilla, and demonstrate how it works against the top 100
webpages, and ones that are known to be bad.  Put some
accessibility-impaired people onto the pages and see if it makes their
experience significantly better in most cases or in most cases just adds
frustration.

>Unfortunately, as "hackish" or unacademic as as it sounds *any*
>information, even a description, cobbled into a description based on the
>function attached is very useful. Today users have *nothing* and you are
>not going to get the legions of JavaScript writers to follow any kind of
>semantic model in the near future. As far as the possiblity of a "lie"
>being there this is unquestionability a strong likelihood but no more than
>people cobbling up bad alt text for images.
>
The problem with "Hackish" is not that it is not academic, but that it
will fail, because it defies the reality of the way listeners are written.

Casting it as an issue of academics does not help prove your case that
treating non-semantic events as semantic and invoking them completely
different from how they were intended to be invoked will work in a
useful percentage of cases.  Your proposal is the one that is not even
academic with nothing to back it up (that I can find anywhere in your
so-called requirements).  You do not answer the charges that it breaks
the listener model.

>If the DOM WG wants to go to a semantic model you need to be able to
handle
>the above. Unfortunately the puritanical approach will leave many people
>out in the cold for some time. My intention is to prevent that from
>happening.
>
I am looking above, and I do not see what you are referring to.  If you
mean we need to enumerate the method names of non-semantic events to
properly handle semantic events, I believe you are completely wrong.

You will leave people in the cold forever.  Give them a yellow sticky
pad that you have scrawled "100 degrees" on, and blame the manufacturer
when it does not keep them warm.  If you had designed a proper solution
to warmth, however simple, we would have made progress.

>So now that we have your undivided attention (:-) how might we solve both
>objectives?
>
The real ones, or the artificial ones?  Solving the real ones amounts to
sitting down and coming up with a plan for semantic events.

Most of what can be done already has:  Permit applications to fire
non-semantic events to simulate events that they have no native access
to.  We can also permit a query about what type of non-semantic events
would be useful to fire at a given point, which will allow deactivation
of application support for event types that are not being listened for
at a given point.

That is very different from what you have asked for, and it will
actually work in the cases where the application can figure out how to
properly construct the events.

Ray Whitmer
rayw@netscape.com

Received on Friday, 21 December 2001 14:02:20 UTC