Re: Next events meeting: 17 Jan 2002 @ 4pm ET

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