- From: Charles McCathieNevile <charlesn@sunrise.srl.rmit.edu.au>
- Date: Thu, 1 Oct 1998 11:25:14 +1000 (EST)
- To: Harvey Bingham <hbingham@ACM.org>
- cc: w3c-wai-ua@w3.org
If there is an 'event cursor' - the current active bit when tabbing around, then many of the mouse events can be understood to relate to the event cursor. The ones that cannot are doubleclicks. Also, if we move from a keyboard model to a 'handsfree' model we may lose the ability to determine keypress/release (or mousdown/up). Taking this approach would allow for such things as rollover highlights to be much more platform independent (although some extra work may be required to create an audio-highlight, it could lead to a greater use of stylesheets which would simplify the programming end, and at the same time create a stronger demand for proper implementation of stylesheets). The cost may be that automatically appearing advertising windows, and the like, would be much more troublesome. (Who knows, this could lead to their demise?) But in general it seems that rethinking these events (in the DOM?) in the context of hardware independence is a good step forward. To a certain extent this is contrary to what Chuck said about the difficulties of a 'browsing cursor' (which is probably a better term than events cursor). It seems to me that this is not such a big problem. Many speech output systems already use a browsing cursor. I had hoped Amaya did so, but it seems to be mouse or mouse. Charles McCathieNevile On Wed, 30 Sep 1998, Harvey Bingham wrote: > HTML 4.0 Attributes that invoke a script: > > onblur %Script; #IMPLIED == the element lost the focus == > onchange %Script; #IMPLIED == the element value was changed == > ondblclick %Script; #IMPLIED == a pointer button was double licked== > onfocus %Script; #IMPLIED == the element got the focus == > onkeydown %Script; #IMPLIED == a key was pressed down == > onkeypress %Script; #IMPLIED == a key was pressed and released == > onkeyup %Script; #IMPLIED == a key was released ==" > onload %Script; #IMPLIED == the document has been loaded == > onmousedown %Script; #IMPLIED == a pointer button was pressed down == > onmousemove %Script; #IMPLIED == a pointer was moved within == > onmouseout %Script; #IMPLIED == a pointer was moved away == > onmouseover %Script; #IMPLIED == a pointer was moved onto == > onmouseup %Script; #IMPLIED == a pointer button was released == > onreset %Script; #IMPLIED == the form was reset == > onselect %Script; #IMPLIED == some text was selected == > onsubmit %Script; #IMPLIED == the form was submitted == > onunload %Script; #IMPLIED == the document has been removed == > > Many of these events depend on the visual positioning of a mouse/cursor. > > These need some analysis of the effects of using keyboard equivalents, and > the different effects that do not have equivalents. > > We mentioned "bubbling up" to a more global handler. > > There may be no event sequence that is dependable when working in a > different user agent. > > The hands-free, eyes-free environment, where vocal command equivalents need > to be recognized, represents another set of challenges. > > Regards/Harvey Bingham > > Regards/Harvey Bingham > > > > >
Received on Wednesday, 30 September 1998 21:50:51 UTC