W3C home > Mailing lists > Public > w3c-wai-ua@w3.org > October to December 2001

Re: Enumeration of EventListeners in DOM Level 3 Events

From: Richard Schwerdtfeger <schwer@us.ibm.com>
Date: Wed, 19 Dec 2001 10:37:58 -0500
To: rayw@netscape.com (Ray Whitmer)
Cc: "Ian B. Jacobs" <ij@w3.org>, Philippe Le Hegaret <plh@w3.org>, w3c-dom-ig@w3.org, w3c-wai-ua@w3.org, w3c-wai-ua-request@w3.org
Message-ID: <OF32403645.A0D3F57F-ON86256B27.0053FF70@raleigh.ibm.com>

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.

>Why try to scab semantic information on top of existing handlers which
typically cannot properly be described that >way.  It is far easier to
separate out specific semantic actions than to try to ascribe semantics to
actions which are >non-semantic because they have to fiddle with the UI and
state and codes.

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.

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

So now that we have your undivided attention (:-) how might we solve both

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.",

                    com (Ray             To:     Richard Schwerdtfeger/Austin/IBM@IBMUS       
                    Whitmer)             cc:     "Ian B. Jacobs" <ij@w3.org>, Philippe Le     
                                          Hegaret <plh@w3.org>, w3c-dom-ig@w3.org,            
                    12/18/2001            w3c-wai-ua@w3.org, w3c-wai-ua-request@w3.org        
                    02:05 PM             Subject:     Re: Enumeration of EventListeners in    
                                          DOM Level 3 Events                                  

Richard Schwerdtfeger wrote:

     One of the problems you and I are both dealing with is the state of
     (almost 2 years ago) with what they are now. Talking about
     implementing a
     semantic model 2 years ago was not realistic. Yes its almost 2 years
     talked about the issues. (January FTF)
Nothing that big has changed.  A simple concept of semantic events made
just as much sense then or now.  It doesn't take all these fancy things you
seem to imply.  The fancy stuff is for hackish scab type solutions.  Design
semantically, and there is no problem.  For 80-20 coverage, it is hardly
more than a new type of event and event object.  If it had been done two
years ago, people would be using it soon and you would be recommending it
     maintain the hackish approach when you can move towards a simple
     design that will be easier for everyone.

     I am listening. I don't disagree that semantic events would be very
     However, I believe that what you would like to impose on a script
     requires an immense amount of work and that web content, in general
     does not support it. Currently, there is no notion of a semantic event
     JavaScript. JavaScript is very low level. Nobody is asking to "hack"
     anything. The problem is there has been a lot of push back to accept
     activation of any form. It is a lot of work for the DOM working group.
You are asking that UI listeners be something other than what they are
naturally -- semantically useful.   Listeners would have to be rewritten
semantically to work the way you want to use them.  I much prefer the path
of actually having official semantic events, even if very simple, rather
than the huge hassle and disappointment of pretend that a UI event is
semantic, when such pretense will break down if it is not, requiring code
to be rewritten in any case but not honestly or sensibly according to the
rules for the event types.

Javascript needs to have no concept of semantic events.  All you have to do
is make a new type of event that IS reasonable to enumerate and activate by
menu.  The first step would be a no-argument version that just carried a
reasonably entry for a menu.  Javascript should not be aware of this type
of thing at all.  Using these is much easier than adding a description to
semantically-undescribable handlers of today.

Separating out actions in this way is not hard for some use cases.  Others
might have to wait until more advanced semantic events were invoked, but
these would likewise not be solvable by scabbing things onto UI listeners.

There was never significant push back to accept event activation.  That is
why it has been there wide open since earliest level 2 -- before we talked
to you 2 years ago -- precisely because most people can think of cases
where it is useful.  Unlike listener enumeration, it is not a broken
          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
          discuss, but you have a lot of broken ideas in this writeup to
     so don't blame us that you didn't do symantic events.  They are not

     I think we are talking about the same thing. Unfortunately, most event
     usage today does not support semantic information and we have to deal
     lots of legacy script on the web. Doing semantic events will not cover
     bulk of what is out there is built on a non-semantic infrastucture in
     case the use of descriptions is very helpful. The legacy information
     have today is onblur, onfocus, onactivate, onclick, etc. Below this we
     an attached function (whatever it is).
The descriptions are useful if you want lies or if your events are already
artificially semantic (ignoring parameters and hardware state, mapped to
high-level functions).  Otherwise, they are not and trying to use them that
way only breeds frustration.

Why try to scab semantic information on top of existing handlers which
typically cannot properly be described that way.  It is far easier to
separate out specific semantic actions than to try to ascribe semantics to
actions which are non-semantic because they have to fiddle with the UI and
state and codes.

Ray Whitmer
Received on Wednesday, 19 December 2001 10:38:34 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:38:32 UTC