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

Al Gilman wrote:

>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 obvious discoverable choices seem to be:

Fire a mouse event with arbitrary coordinates (may or may not work).

Fire an arbitrary keystroke (most likely not to produce a desirable 
outcome, since people usually care which key was pressed, unless it was 
a generic activation or they may be using this as a way of detecting 
when a value typed into a field was modified (which should be 
automatically fired by any agent).

I do not understand your use of the word ambiguous.  It is certainly not 
equivalent.  In neither case would you have a guarantee that the 
manufactured event would have a particular desired result, but in the 
one case, the user is, apparently erroneously, not told that firing an 
event at this node might be important because it erroneously rules out 
listeners registered on ancestors.

>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.
>
I do not think it is a forgone conclusion that ALL providers will find 
it problematic.  Not permitting users to navigate further if they need 
to seems to be a mistake, and I would believe that not presenting the 
options of ancestor nodes once you have navigated down seems to be an 
error as well.  If I were implementing this, I might explore 
alternatives, since what has been described doesn't sound particularly 
reliable.  For example:  The initial tabbed navigation takes users to 
all roots of hierarchies where specific event handlers of interest 
declared.  If someone has a web page with the perfectly-separated 
handlers, then they will likely be on the roots of the hierarchies in 
question.  This is the only clean case.  Once at a particular node, 
there might be another navigation keystroke besides tab for more complex 
pages to enter child nodes, any one of which might also need to have 
events delivered to it.  While it would be cumbersome for someone who 
was dealing with a simple page to enter child nodes as part of the 
primary sequence, it would be essential for someone who was dealing with 
a complex web page.  Without it, there is an insurmountable barrier of 
accessibility.

While this approach described thus far does not seem to benefit from 
querying for which listeners are locally defined, I can see that you 
might add any node with explicit declarations to the initial tab 
sequence, even if it did have an ancestor that had already declared 
them.  This would be probably a much-less-common case, but in this one 
indistinguishable case -- where both a parent and a child have declared 
a handler for the same event -- I can see that it might be useful.

OK.  I can buy that this is enough advantage that both modes should be 
supported.  But I think it would be a bad thing once the user navigated 
to the child, either directly via tab stop or by entering the child 
heirarchy, to not present all the relevant events that have handlers for 
that location, including those declared on ancestors.  There is nothing 
in your use case description to indicate that you would want to deny the 
user this capability and leave such arbitrary barriers to accessibility.

>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.
>
It is easy, but does not handle the one case.  Still, when presenting 
the options on a particular node, I think you should present all 
available on the node, not just those declared at that node, so once you 
have used this function to create your navstop list, you shouldn't be 
using it to present options to the user, and I think there should be 
alternative navigation into at least the child elements of any nav stop, 
which doesn't get in the way, but permits more complex navigation where 
it is required, because even if it is less common, events may be 
expected on the child nodes.

>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.
>
Yes, I agree with this.  For producing the nav stop list, it solves one 
more case, that may be less common, but is useful.  What has clouded my 
picture of things in the past is claims that the more-complete query 
would not be used, whereas it is still clear (to me) that it should be 
used for the options presented at any node where the user navigates to, 
IMO.  You can manufacture the information by climbing around on the 
hierarchy, but omitting the complete query might lead vendors to offer 
incomplete options on the node through neglect rather than through 
design, whereas having a flag for "all handlers receiving events from 
this node" versus "only locally-declared handlers" makes it more 
obvious, I think.

>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.
>
Thanks.  It has helped me.

Ray Whitmer
rayw@netscape.com

Received on Thursday, 17 January 2002 14:20:42 UTC