- From: Ray Whitmer <rayw@netscape.com>
- Date: Fri, 04 Jan 2002 13:57:07 -0800
- To: Jon Gunderson <jongund@uiuc.edu>
- CC: "Ian B. Jacobs" <ij@w3.org>, plh@w3.org, lehors@us.ibm.com, shane@aptest.com, gleng@freedomscientific.com, charles@w3.org, asgilman@iamdigex.net, w3c-wai-ua@w3.org
As before, I disagree with your personal opinion on these issues, and only by producing the use cases can we work through them, evaluate them, and gain consensus. I suspect that some people will want a higher quality of information about the handlers than you are expecting and allowing for in your suggestions. What you are proposing here is to not supply an accurate description of the handlers as they are available in the hierarchy, which are not semantic and do not follow your rules just because you wish they were semantic. I do not believe what you have described here lays a good foundation for either proper use of non-semantic events or for semantic events when someone finally realizes that that is what we need them and they are not so difficult. I strongly oppose any new feature which anticipates encouraging people to rewrite their current pages without fixing them and making them properly semantic. That includes adding descriptions to non-semantic events. It is trivial to add semantic descriptions (no new DOM code required, just look for a new attribute on the node which can easily be accessed through DOM) but it should only be done with semantic events to accomplish the use cases I have seen thus far. Writing technical specifications into use cases does not help. Saying "we need to enumerate event handlers" is a horrible example of a use case because it ignores the actual needs, and my answer is simply, no, you do not need to enumerate handlers. You are saying we need handlers to be user-selectable. But they are not. You need to design them that way and we could have had them that way by now... It is quite possible that a first stage would be practical with NO changes to a DOM level 2 browser. You just have to make your document handle new event types with semantic descriptions that page writers are encouraged to fire from non-semantic handlers to accomplish the real work. The DOM model already permits that. If you make a new event type called "SemanticAction" with an extra string semantic identifier property, and another new event called "SemanticEnumeration" with a way to accrue identifiers through some property of the event, then the same handler that decides conditionally whether it will handle an event based upon which node it originated on can let any node that asks (by firing the enumeration event) that it would perform a semantic action if it received the event generated from that particular node. The availability can now even be stateful. Now, when you ask people to rewrite their web pages, you have them supply and enumerate actions that might be semantically useful to someone who does not have the device in question into those events, which can be described well because they are semantic, not tied to a device. They keep all the device-specific stuff in the non-semantic events, and then fire the semantic ones when it gets to the point that it would be useful as a user-selectable event. It is a model that works, because it was actually designed. That doesn't mean it takes a long time to roll it out because the event support is already there. That seems to me to be the proper way to do it. And you don't hard-wire yourself to an unrealistic model that assumes that handlers are declared on the nodes for which they are performing actions. This probably covers 80%, but obviously, there is more that can be done here if you want the invoker of the SemanticEnumeration and SemanticAction to know how to supply additional arguments such as simple values or association with a second node (for things that in a UI would be a drag-and-drop type action), etc. It is hard to see in any of this where we need new DOM features. Describing these semantic events would be a proper thing. Ray Whitmer rayw@netscape.com Jon Gunderson wrote: >> Todo: The WAI groups need to provide a use case of when it's useful >> to know that an event handler was declared on the current node >> and not an ancestor. > > > JRG: I think we only want current node. We have no real use for > bubbling information at this point. > >> 2) What's the best place to describe the semantics of >> author-specified behaviors? >> >> We have not progressed much on this issue. However, there is >> some sense that this is more of a format issue than a DOM issue. >> >> Ray has stated that it doesn't make sense to be able to >> specify descriptions on a per-handler basis if you can't >> activate handlers individually. >> >> Question: Would it be useful for the DOM to provide all >> descriptions of all handlers for a given event type? Or >> should we specify instead (one or more) descriptions for an >> event type (rather than handler)? > > > JRG: This seems to be more a markup issue. The markup language should > provide a means to associate the purpose/function of a script to a > particular event handler. One possible solution is some thing similar > to the label element for form controls. This would be considered > conditional content, form a UAAG point of view, and could be made > available to the user through the DOM or the User Interface. > > > >> Please indicate what other questions WAI or the DOM WG or the >> HTML WG should answer. >> >> [1] http://lists.w3.org/Archives/Public/w3c-wai-ua/2001OctDec/0135 >> [2] http://lists.w3.org/Archives/Public/w3c-wai-ua/2001OctDec/0132 >> [3] http://www.w3.org/TR/xml-events/ >> -- >> Ian Jacobs (ij@w3.org) http://www.w3.org/People/Jacobs >> Tel: +1 718 260-9447 > > > Jon Gunderson, Ph.D., ATP > Coordinator of Assistive Communication and Information Technology > Division of Rehabilitation - Education Services > MC-574 > College of Applied Life Studies > University of Illinois at Urbana/Champaign > 1207 S. Oak Street, Champaign, IL 61820 > > Voice: (217) 244-5870 > Fax: (217) 333-0248 > > E-mail: jongund@uiuc.edu > > WWW: http://www.staff.uiuc.edu/~jongund > WWW: http://www.w3.org/wai/ua > >
Received on Friday, 4 January 2002 16:57:52 UTC