- 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
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.
>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
happening.
So now that we have your undivided attention (:-) how might we solve both
objectives?
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-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:
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)
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
today.
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.
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
concept.
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).
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
rayw@netscape.com
Received on Wednesday, 19 December 2001 10:38:34 UTC