- From: Ray Whitmer <rayw@netscape.com>
- Date: Tue, 19 Feb 2002 08:19:17 -0800
- To: Charles McCathieNevile <charles@w3.org>
- 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>
Charles McCathieNevile wrote: >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: > This proposal of two new events does not address existing web content by itself. For existing web content we have the methods in the DOM Events specification that we recently defined and those that were there before. The two techniques may be used together -- the methods for non-semantic events that the agent knows how to fire, and the new events for semantic events with better-understood activation models and better descriptions. These new events are clearly semantic. We are not putting both semantic and non-semantic events into the same enumeration because they are complimentary, although the agent may present them together. If they were enumerated together without distinction as to non-semantic type, it would not work because the event structure passed to semantic events is different from the structure passed to non-semantic events. Semantic events will typically have semantic names. Non-semantic events will be named however the agent likes (including "click") since the agent is testing for the presence of a specific type of event which is event-specific in how it is fired. >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. > It is good to be able to do semantic events declaratively with xml events and have such things handled automatically, but I believe it must be compatible with the procedural way of enumerating events, which is more functional, even if more complex. For example, declarative XML semantic events might be a shortcut that underneath, wraps the simpler handler declaration in the required procedural agents -- not unlike what happens today with HTML declarative events mapping to calls to add the handlers. Pages could still use the procedural agents. The accessibility agent does not directly need the declarative form, because the enumeration event is giving it all the info it needs. You probably already realize this, but the design of the two events was intentionally such that there was no declarative enumeration of event names and descriptions is required. Instead, an event listener, similar to the one that will handle the semantic event, enumerates which events are available on a particular node and its descendants. There are good reasons for this: 1. It permits web content developers to develop content using the new events that can be used by semantic-aware agents inside of existing browsers. 2. It permits features to be dynamically judged "available" or "unavailable", based upon the state of the document. For example, perhaps I have a button that sums a column. I want the column-summing feature to only appear when there are actually values to sum. Or perhaps the form cannot be submitted without fields passing verification, etc. 3. A semantic event handler can be declared on a single node anywhere in the hierarchy and choose to accept or reject events targeted at all descendant nodes. It only makes sense that you can declare a handler on the same node that enumerates the types of events handled for the descendent nodes or we are back with the same problems of not really knowing which nodes accept which semantic events. >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... > I agree that XML events is a great opportunity to make things easier and give browser developers an incentive and easy path to add support for semantic events, which would also work without browser intervention (given DOM level 2, and better in DOM level 3) but could make the declarations easier and support something like a right-click even when there is no agent running. We need a very smooth path, with clear new standard milestones along the way to really get it functional, such as XML Events presents. Best regards, Ray Whitmer rayw@netscape.com
Received on Tuesday, 19 February 2002 12:42:26 UTC