Re: on events with different UA ???

Good questions.  Here are some related thoughts.

The 'onblur' and 'onfocus' events are not direct products of user
manipulation of command devices.  They are outputs of a state
machine driven by these inputs.  For example, TAB moves the focus
from one element to another.  The user keypress just says "move"
and something in the document knows what to move to.  I think
that we will need to treat externally generated events
differently from events which come out of such a state machine.

The Archimedes project at Stanford offers a working example of an
alternative command vocabulary used for voice.  But all their
voice commands are macros that talk to the shrink-wrapped
software through the identical set of events it was expecting,
and the shrink-wrapped software behaves just as it normally does.
There is no concept of "replacing" part of the existing
processing, just a pre-processor layer that expands a voice
command into a set of mouse-and-keyboard emulation events.

The present situation does not tell use enough about scripts
to tell us what needs to be done to adapt them for different
user capabilities and I/O devices.  Chuck's example of the
virtual image map script read the mouse coordinates to decide
what to do; it did not simple respond to the clicking of the
mouse button but that is what kicked it off.  To be able to
say what has to be done to adapt the behavior of a given script,
one needs to know more about its behavior.  At a minimum this 
means knowing what things it can change, and what information
can influence how it changes those things.

If a script fires on a mouse click and then reads the mouse
coordinates to decide what to do, it is not enough to have the
click event created by an alternative command device.  To access
the full range of behavior of the script, it is also necessary to
arrange for the mouse coordinate information expected and read by
the script to be controllable.

Al

to follow up on what Harvey Bingham said:

> The draft Jon circulated 12 hours ago:
> 
> Techniques: 
> 1. Sequential keyboard access to explicit events associated 
> with an element. [+P1][+Tnav-dhtml-sequential] 
> 2. Direct keyboard access to explicit events associated with an element.
> [+P1][+Tnav-dhtml-direct] 
> 3. Keyboard equivalents for simulating mouse explicit events.
> [+P1][+Tnav-dhtml-simulate] 
> 
> For reference to what we are discussing, the list of "on..." event 
> attributes in HTML 4.0 are:
> 
> onblur      %Script; #IMPLIED -- the element lost the focus --
> onfocus     %Script; #IMPLIED -- the element got the focus --
> onkeydown   %Script; #IMPLIED -- a key was pressed down --
> onkeypress  %Script; #IMPLIED -- a key was pressed & released --
> onkeyup     %Script; #IMPLIED -- a key was released --
> 
> ondblclick  %Script; #IMPLIED -- a pointer button was 
>                                   double-clicked--
> onmousedown %Script; #IMPLIED -- a pointer button was pressed down --
> onmouseup   %Script; #IMPLIED -- a pointer button was released --
> onmousemove %Script; #IMPLIED -- a pointer was moved within --
> onmouseout  %Script; #IMPLIED -- a pointer was moved away --
> onmouseover %Script; #IMPLIED -- a pointer was moved onto --
> onselect    %Script; #IMPLIED -- some text was selected --
> onchange    %Script; #IMPLIED -- the element value was changed --
> 
> onsubmit    %Script; #IMPLIED -- the form was submitted --
> onreset     %Script; #IMPLIED -- the form was reset --
> onload      %Script; #IMPLIED -- the document has been loaded --    
> onunload    %Script; #IMPLIED -- the document has been removed --
> 
> Many of the above apply to most all the element types.
> 
> In a mouse-free environment I doubt that there is a 1:1 correspondence 
> with the alternative mouse/cursor/focus/select mode of control. So, 
> some keyboard sequence maps to the particular "on..." event.
> How is this conveyed to a UA, and to a user?
> 
> It is unlikely that the same keyboard sequence (including various
> Ctrl/Shift/Alt concurrent keys) are appropriate for voice commands.
> 
> Is it correct that the single script named in the CDATA of any 
> of those %Script; must handle the variety of responders for the 
> different media?
> 
> If so, does some pre-processor have to map from the keyboard/voice command
> onto the proper "on..." attributes identifying the %Script; and supplying
> the same information (positional, and select/focus/blur) as if it came as a
> result of some prior or current mouse/select/keypress/etc. to process that
> request for action with the single specified %Script; .
> 
> How does one substitute a different set of scripts? Can their names be 
> indirect, so a user preference set of scripts can participate in determining 
> which particular scripts are to be used/substituted for the specified one?
> 
> Is it our job to anticipate how this mapping might be done? or only that
> a mapping is required? or that alternative, more appropriate %Script;
> might be substituted for the particular usage command set/presentation form?
> 
> Questioning/Harvey 
>

Received on Thursday, 15 October 1998 08:35:16 UTC