Re: Enumeration of EventListeners in DOM Level 3 Events

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 Thursday, 20 December 2001 14:30:50 UTC