- From: Charles McCathieNevile <charles@w3.org>
- Date: Tue, 19 Feb 2002 06:07:39 -0500 (EST)
- To: Ray Whitmer <rayw@netscape.com>
- cc: "Ian B. Jacobs" <ij@w3.org>, <plh@w3.org>, <lehors@us.ibm.com>, <shane@aptest.com>, <gleng@freedomscientific.com>, <jongund@uiuc.edu>, Al Gilman <asgilman@iamdigex.net>, WAI UA group <w3c-wai-ua@w3.org>
OK, first to make sure that I understand clearly what is being proposed - otherwise my response to it is misinformed. With Ray's proposal we are asking people to create two DOM events (as specified), which means that they are using existing DOM2. If we include this in the specified set of things we expect to be implemented (for example by User Agents) then doing so is not difficult for a DOM implementation. These events will allow a user to right-click (or otherwise appropriately arm) an object, and receive a list of the event listeners which are listening to that event (somewhere in the bubble/capture phase) So for existing Web content, the user could expect to see events with names like click, mouseover, etc. But it is trivial to write events that have useful names instead, which solves the future case, it is easy to write events with real names that fire the events currently called click, focus, etc, so current content can readily have the new system ayered over it, and users will learn the small range of behaviours that is mostly associated with the current device-based event listener set in practise. If all the above is true (i.e. if I have correctly understood what Ray was proposing), then I propose that WAI adopt the following approach: 1. We adopt Ray's proposal. We ask that it be developed as part of the DOM specifications, and that it be incorporated as part of user agent requirements / techniques for providing access to interactivity. 2. We further request, of the XML events group, that their namespace include a method for referring to a description of an event - prefereably by IDREF / URI so it can be usefully an attribute, although an element (such as the desc child of the animate element in SVG) which can have parseable XML content or have an xlink:href pointer would be even better. (I don't think that it fits all the use cases XML events is required to support. Further discussion might suggest that both should be available in the namespace). I believe that this information would the be queryable using the existing DOM, although again we would have to specify it as a user agent requirement / technique to be implemented. This should give us a method for finding out what events are available at a particular element which is easily implemented and covers past present and future cases, and a method for future cases that allows us to get further information about an event than a name, for users who need it. (Compare the model in xforms of hints and help as another example of this approach). This proposal might still contain errors of fact - please check it... cheers Charles On Wed, 16 Jan 2002, Ray Whitmer wrote: I offer the following as my preferred alternative to every proposal I have heard to change the markup language with respect to events to make pages more accessible. It addresses short and long term needs: Define two simple new events: interface Action:Event { readonly attribute DOMString name; } interface ActionList:Event { void addAction(in DOMString name, in DOMString description); } When you want a list of actions on a a target, you fire the ActionList event at the target, and listeners list the apropriate semantic actions. Then you put them on the menu. When the user selects one, you fire the Action event with the selected name, and listeners handle the semantic actions.
Received on Tuesday, 19 February 2002 06:07:52 UTC