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

At 09:27 PM 2002-01-16 , Ray Whitmer wrote:
>
>With a very good solution for the future in place, I respectfully 
>suggest that the only short-term solution we should consider is a 
>boolean test for listeners, wherever they may be declared, that receive 
>events of a specified type originating on a specified node.  Otherwise, 
>as requested previously, please give more specific use cases why more 
>than this is essential.
>

This relates to Jon's agenda item 1.

1. How many boolean functions to test for listeners?
a. Nodes with excplict event handlers
b. Nodes with event handler attached

Let me start by trying to explain the putative use case a little more.  I
wasn't grasping the critical role of the navigation requirement in UAAG to the
utility of the handler information until we went over it in the PF telecon.

The use case involves filtering the set of DOM nodes down to a navStop subset
that are required navigation destinations.

The user is provided with non-pointer means of discrete, focus-moving
navigation (whether incremental or absolute is implementation defined, but
there has to be some navigation method that gets you to all the navigation
destinations identified in the first step).

At the user's option when the focus is at some node the user may query for
"what other actions can I take here?" somewhat analogous to the context menus
supported in many graphical user interfaces.  The user is presented with a
range of choices by some dialog, and on user election an event is fired at this
node of some name which the DOM query says is handled when fired at this node, 
[Note this is ambiguous as to whether the query returns "event types bound
here" or "event types [prima-facie expected to be] handled when fired here." 
The difference is in step 1.

The current baseline from past deliberations in the UA Working Group for the
maximum set of required navigation stops to use in the above use case is those
nodes where event handlers are explicitly bound at that node.  Providing
generalized-tab-sequence navigation over all nodes in the DOM tree was judged
to be so diffuse and slow that nobody would use it, defeating the purpose of
the access to latent actions that this repair functionality is supposed to open
up.

A candidate next-best substitute for that set of nodes, if the DOM will only
tell you "what event types will be handled when fired here" is to do the
functional equivalent of a trace down the path to all DOM nodes, inspect the
boolean-vector-valued "event types handled if fired here" vector and set a
navStop mark on any node where this changes on the pass down the path.  Any
node which as a different "event types handled if fired here" property from its
parent would be included in the navStop set, others would be ignored.

This will give a somewhat smaller set of navStop nodes, but it is "within the
competitive range" of solutions where we should examine the costs and benefits
in more detail.  Not to be dismissed out of hand.

The difference is that nodes whose only eventType handlerBinding is for an
event that has a handler bound further up the tree by another node will appear
under the UA baseline navList specification, and will be absent in the above
candidate which can be produced from the DOM initiated alternate definition of
the handlers? query.  Now, clearly if there is a fresh binding for an eventType
bound elsewhere, this is prima_facie evidence that the behavior will be
different in response to firing the event at the lower node vs. the upper
node.  So there is high plausibility that adding this particular (eventType,
node) pair to the firings available through the adapted interface is of
substantive benefit.  Dunno how often it happens, but there are certainly some
instances of this.  So this leaves us inquiring about the cost on the DOM
side.  It would seem that a simple syntax-aware response dealing with "what did
the document [and post-load listener registrations?] say?" would not be a great
burden to produce.

The perceived downsides would appear to be a) it's grody, let's do something
clean, and aligning the scope of the query with the response to firing events
at nodes (Charles's recapitulation of Ray's position).

I have tried to elucidate the difference in "plausible value added to the user"
for the two different variants on the use case appropriate to the two different
forms of DOM query.  Hope this will help us start at a higher point on the
learning curve this afternoon.

Al

>Ray Whitmer
>rayw@netscape.com
>

Received on Thursday, 17 January 2002 11:43:11 UTC