W3C home > Mailing lists > Public > w3c-wai-ua@w3.org > July to September 1998

Re: HTML 4.0 Strict DTD Events

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
Message-ID: <Pine.SUN.3.91.981001110702.8655A-100000@sunrise.srl.rmit.edu.au>
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

This archive was generated by hypermail 2.3.1 : Friday, 13 July 2018 11:53:07 UTC