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

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