- 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