- From: Charles McCathieNevile <charles@w3.org>
- Date: Sat, 5 Jan 2002 00:06:39 -0500 (EST)
- To: Jon Gunderson <jongund@uiuc.edu>
- cc: "Ian B. Jacobs" <ij@w3.org>, <rayw@netscape.com>, <plh@w3.org>, <lehors@us.ibm.com>, <shane@aptest.com>, <gleng@freedomscientific.com>, <asgilman@iamdigex.net>, <w3c-wai-ua@w3.org>
On Fri, 4 Jan 2002, 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. CMN I disagree. I don't think it is that much of an accessibility-specific need to find out where the event is declared - whether it is on the element or on a parent the point is to know that it can be fired from that element. >2) What's the best place to describe the semantics of > author-specified behaviors? > >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. CMN Seems sensible to me. When declaring an event handler, and what it triggers, there ought to be a method for associating a description with the event. An example use case might be as follows. Navigating through a page, I find an item that is active (i.e. it will respond to some event trigger - it might be identified in a similar way to links being identified, after all they are the original active elements in HTML). I can query, for example with a context menu, what are the triggers I can fire here? Ideally, there is a title associated with each event trigger, for the function that it calls. This would mean that I could select the trigger to fire from a list of titles, rather than just guesssing at a behaviour from a specific device I may not have. Even more ideally, I can ask for a description as well as just a title. In either case it doesn't seem to matter whether the event is declared on the element I am interested in, or whether it will be passed through the capture/bubble mechanism. In the real world of the legacy content that will persist for a while while the new ideal system is being adopted, the titles of events will be things like mousedown, mouseup, keypress, etc, and we are not likely to have a description for them at first (althugh tehre are a lot of scripts that could be identified as rollover highlight, or onchange navigation fairly easily, so if it were very simple to associate an out-of-line decsription, especially through a mechanism like annotea annotations or out-of-line Xlinks, this might be done for a useful proportion of pages with a robot. cheers Chaals
Received on Saturday, 5 January 2002 00:06:46 UTC