- From: Richard Schwerdtfeger <schwer@us.ibm.com>
- Date: Tue, 18 Dec 2001 13:24:39 -0600
- 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
Ray,
One of the problems you and I are both dealing with is the state of things
(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 we
talked about the issues. (January FTF)
>What you are fighting for here is useless. Start listening. Hacking UI
events will never be a good solution, no matter how you decorate them.
>Especially as you begin adding new requirements on the script writer, why
maintain the hackish approach when you can move towards a simple >semantic
design that will be easier for everyone.
I am listening. I don't disagree that semantic events would be very useful.
However, I believe that what you would like to impose on a script writer
requires an immense amount of work and that web content, in general today,
does not support it. Currently, there is no notion of a semantic event in
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 event
activation of any form. It is a lot of work for the DOM working group.
>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 could
>discuss, but you have a lot of broken ideas in this writeup to overcome,
so don't blame us that you didn't do symantic events. They are not that
>hard.
I think we are talking about the same thing. Unfortunately, most event
usage today does not support semantic information and we have to deal with
lots of legacy script on the web. Doing semantic events will not cover the
bulk of what is out there is built on a non-semantic infrastucture in which
case the use of descriptions is very helpful. The legacy information we
have today is onblur, onfocus, onactivate, onclick, etc. Below this we have
an attached function (whatever it is).
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.
com (Ray To: Richard Schwerdtfeger/Austin/IBM@IBMUS
Whitmer) cc: "Ian B. Jacobs" <ij@w3.org>, Philippe Le Hegaret <plh@w3.org>,
w3c-wai-ua@w3.org, w3c-wai-ua-request@w3.org, w3c-dom-ig@w3.org
12/18/2001 Subject: Re: Enumeration of EventListeners in DOM Level 3 Events
12:54 PM
I have removed www-dom because I believe you have referred to discussions
that are not public. I added instead w3c-dom-ig.
Adding the event type enumeration only fixes a small part of the fact that
it is broken. There is no justification to ignore the other issues that
have been repeated here. Enumeration of types leads to broken thinking
about listeners, and enumeration of listeners is even worse because there
are already methods for properly dispatching an event of any given type at
a given node and the only reason to enumerate them would be to invoke them
improperly.
The place to get a list of possible types is from a specification, not from
an enumeration, because you cannot dispatch previously-unknown types. The
proper way to dispatch events to the listener is to call the dispatch
function. And best way to know whether a listener responding to a specific
type that you know and care about is present would be to ask specifically.
Enumerating the types at a single node doesn't tell you the listeners that
will respond to events on that node, and gives you more information that is
useless and likely to be harmful.
In all of this, there is no real justification for enumeration of types or
listeners. The use cases we have seen only require knowing whether
handlers will receive specific events of known types of a given node
(notice that I did not say at a given node, because that is not the same as
of, which is another part of what is broken with the enumeration). Since
DOM Level 2, you can fire an event, and not in the haphazard way that is
most likely to result if someone is manually invoking listeners, that will
break the assumptions of the script writer about delivery of events
according to the specification.
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?
We had no problem with our requirements -- only with those represented as
coming to us "from WAI", which are broken and do not support use cases.
I was told that the requirement that this feature was based upon was "let
us enumerate listeners". If you had emphasized "let us enumerate listener
types" instead of "let us enumerate listeners", I suspect that we would
have been happier to do that instead. But either enumeration is broken
when dictated as a requirement, because it ignores the real problems that
needs to be solved and insists on a broken solution that doesn't even solve
the problem at hand.
How does the application construct the proper event, by trial and
error?
First, an authoring tool ought be able to do this. How might you
expect a
person to create an application without this capability? I also
believe
this may be implementation dependent.
Applications can only do this about event types they know about.
Enumeration of event types you do not know about is useless at best. The
ability to deal with a specific event type comes from an application
following a specification. Events which are implementation dependent
without subscribing to a standard specification cannot be properly invoked
by an application. This is the fallacy of the thinking (that lead to the
current situation) that you can blindly:
1. enumerate the events
2. list them on the menu
3. invoke them from the menu
A far more real description would be:
1. Identify certain user-based event types that certain classes of users
cannot generate due to an alternative UI -- this has nothing to do yet with
what has been registered.
2. Carefully construct handling with alternate user interface for these
types. For example, a keystroke requires a code, a mouse requires a
position and button state, etc.
3. Permit the user to fire the carefully constructed events at the node in
question. Presumably requiring the user to numerically speak the key codes
or mouse coordinates is a bad thing so there is a significant amount of
effort to design a suitable alternative UI for firing many UI events.
The ability to do this is already completely available from DOM as it
exists today. All that is missing is
4. Permitting these known specific event types to be omitted from the
accessibility menu if there are no known listeners. This neither requires
nor suggests as a good solution enumeration of listeners, which there is no
reason for, nor even enumeration of event types registered on a particular
node.
What if the user chooses to invoke functions that should never be
user
accessible, such as mutation events.
If you new the "type" of event you could selectively pick those which
you
fire. So what might happen if the mutation event was fired. ...
probably
nothing since the application would look to see what changed.
It is quite possible to send bad info and crash the application by giving
it a previously-impossible situation, such as a null reference.
Willy-nilly invoking of handlers is not a good idea. Any application which
permits events to be erroneously fired is badly broken. The application
discussed here should only fire well-designed UI events, and enumerating
lots of handlers it is clueless about is worse than useless.
Far better to ask a question, "are events of this specific type that I can
generate well handled by a listener"?
How does the DOM Level 3 script know which event type definition
applies
to the function, or which listeners must only be invoked in
concert?
Another requirement that I had placed on DOM 3 for PF was to be able
to
have a description for each event. Currently, there is no mechanism in
script to store a description of the event function executed so I when
I
met with PF for DOM 3 I had asked that the function name be stored.
Lauren
Wood thought this was not an unreasonable request at the time.
That's easy. The function name is "handleEvent". Look at the IDL. You
can make it a constant in your program, but it solves no problems.
Javascript implementations may make a wrapper outside of DOM of an
arbitrarily-named function, but according to the DOM specification, the IDL
fixes the name, and if you give Netscape an object, as the specification
states and do not rely on this wrappering, it must be named handleEvent.
Also, it is flawed to present this name as a menu item to a user, because
it implies that he can invoke the single handler individually, and it would
be broken to do so, because handlers of a specific type work in concert.
One key handler may handle the letter "Q" to quit a specific mode. The
parent may handle all other keystrokes. The only way to properly invoke
the key handlers is together. Even if it says "QuitState", it will not
quit the state of the program unless it gets the Q and the proper way to
fire a keystroke is at all applicable handlers until one cancels. They are
likely to rely on each other.
These are all fine questions. The bottom line here is that the DOM
working
group only implemented part of the requirements. There is not much I
can do
about that except that that if DOM 3 needs to be an interim step to
where
we want to go then lets take it. I would love to have had the DOM
working
group include all the PF requirements but you are going to do what you
are
going to do.
These PF requirements are very poor and broken. Hacks at best that won't
work well a majority of the time. We have talked to you for quite some
time about your specifying semantic events (that would make sense to
enumerate and would be able to automatically appear on a menu, etc.) but
you haven't done them, and "you are going to do what you are going to do".
This is much better than the hacks you are pursuing today, IMO.
The bottom line is several of the DOM group objected to the requirements --
as we did at the time -- because they said "enumerate listeners", which was
obviously broken and had already been repeatedly rejected for similar
reasons. But it kept getting left in because it came from WAI, ignoring a
discussion of the merits. It needs to be fixed or eliminated. If the
requirements had had anything to do with the real accessibility use cases
and had acknowledged the existing state and design of DOM, then we would be
a lot further along today.
What the DOM WG needed to do is:
Enumerate all events by type
For each event provide a description for future script writers to
be
able to store a text description. For now DOM implementers should
store
the function name here. (We had discussed this when I met at the
face to
face)
Allow the user to be able to fire each event based on the
information
received from the type and description.
An event is something that is delivered to a listener. There are never any
events attached to a node to enumerate.
Enumerating listeners is a very broken approach, because the code itself is
the most concise description of what a handler will do. As much as you
would like them to be semantic, they are not. Just adding a semantic
description does not help in the least. The function name is a constant.
And if you had access to it, it would be improper at several levels, as I
have explained, to present it to the user. The DOM implementation knows no
function name, because according to the DOM specification, the name of the
handler is always the same. Even if it did, it would be completely wrong
to present it to the user except in a few limited circumstances that you
have not advocated a way of detecting.
I will strongly oppose the ability to individually fire events -- not in
concert as the DOM specification requires -- because it breaks
compatibility with DOM level 2 and breaks the assumptions people make when
they write scripts -- that they work in concert. If you want that type of
model,design it. Don't blame other non-semantic systems for not being
semantic.
You can keep trying to shift blame, but the problem is that the WAI group
has not produced semantic events, which has been ignored for quite some
time. Then, the accessibility guidelines can require that for
accessibility purposes, non-semantic events should restrict themselves to
dealing with the UI and then invoking semantic events.
What WCAG needs to do is:
Define industry standard techniques for storing functional
descriptions
in web content.
This is entirely wrong. Even if you could store a functional description
of what a particular mouse click handler would do, it would be nearly
impossible for an accessibility provider to intelligently use a description
of what many, and likely most, typical UI event handlers do.
You need to simplify, and use semantic events to establish a level that can
be intelligently invoked from alternative UIs.
Come up with standard descriptions for common functions.
Document a way for DOM implementers to retrieve them.
Work with standards bodies, like that for ECMA script, to hav them
accepted.
This is way more than you need to do, and the result is not as useful as
simple semantic events.
People working in accessibility have had to fight for every beach head
they
can get. If the DOM working group implements part of what we asked in
level
3 then it is easier to get the rest in 4.
What you are fighting for here is useless. Start listening. Hacking UI
events will never be a good solution, no matter how you decorate them.
Especially as you begin adding new requirements on the script writer, why
maintain the hackish approach when you can move towards a simple semantic
design that will be easier for everyone.
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 could
discuss, but you have a lot of broken ideas in this writeup to overcome, so
don't blame us that you didn't do symantic events. They are not that hard.
Ray Whitmer
rayw@netscape.com
Received on Tuesday, 18 December 2001 14:24:54 UTC