W3C home > Mailing lists > Public > w3c-wai-ua@w3.org > January to March 2001

Re: Navigation without side-effects

From: Ian Jacobs <ij@w3.org>
Date: Thu, 08 Mar 2001 13:01:26 -0500
Message-ID: <3AA7C8F6.88413532@w3.org>
To: Al Gilman <asgilman@iamdigex.net>
CC: Denis Anson <danson@miseri.edu>, Aaron Leventhal <aaronl@netscape.com>, w3c-wai-ua@w3.org
Al Gilman wrote:
> 
> Yes, but Aaron mis-represented the function asked.  It is not that the focus
> doesn't go to the element.  It is that the onFocus response doesn't fire 
> right away when this happens.  
> Think of it as anaesthesia, or the interpolation of a process step.
> 
> The desire is to break the instantaneous and automatic link between the state
> transition where an element gains focus and the firing of a nominally onFocus
> event response.
> 
> It is an adjusted protocol for the response to the action,
> not a change in the
> action.  The element truly gains focus, as defined by the 
> stable rules about where keyboard events act, etc.

This does raise questions about what *exactly* should not happen
in this configuration. For example:

 a) Should stylistic effects be suppressed (either those specified
    through style sheets or those implemented natively by the UA)?
    I presume not, since I would not otherwise know where I am.

 b) Should *all behaviors* be suppressed, or just those handlers  
    specified by the author? At the ftf meeting we talked about
    handlers attached to the DOM by ATs (and the inability to
    quickly distinguish them from author-supplied handlers; you
    can distinguish by looking at the explicit event handler 
    attributes for the case of HTML). What about implicit
    behaviors that the UA implements (e.g., when you move the
    focus to a link in Lynx, there is highlighting of the
    focused content)?

At the ftf meeting we said:

  "The user must be able to configure the user agent so that 
   moving the content focus to an enabled element does not
   automatically activate any of the associated actions."

I think we need to be more specific about what we mean. 
I want to start by assuming that we only mean author-supplied
behaviors for the following reason: This is here to a large
extent to allow repair of author-supplied device-specific handlers.
The user agent is expected (required) to allow the user to
use the keyboard for all functionalities, no repair required.

It will be hard to say: "Move the focus, but don't do anything
stylistic and suppress the behaviors implemented natively that
are attached to the focus changes." It will be easier to say
"Don't trigger author-supplied handlers."

Having said this, it's not even easy to do that with the bare
DOM; the UA is going to have to manage the data privately 
to a certain extent.

 - Ian

-- 
Ian Jacobs (jacobs@w3.org)   http://www.w3.org/People/Jacobs
Tel:                         +1 831 457-2842
Cell:                        +1 917 450-8783
Received on Thursday, 8 March 2001 13:01:53 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 October 2009 06:50:38 GMT