Re: Navigation without side-effects

User can turn off styling if they want to, if a user agent conforms to our 
specifications.

Jon


At 01:01 PM 3/8/2001 -0500, Ian Jacobs wrote:
>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

Jon Gunderson, Ph.D., ATP
Coordinator of Assistive Communication and Information Technology
Division of Rehabilitation - Education Services
MC-574
College of Applied Life Studies
University of Illinois at Urbana/Champaign
1207 S. Oak Street, Champaign, IL  61820

Voice: (217) 244-5870
Fax: (217) 333-0248

E-mail: jongund@uiuc.edu

WWW: http://www.staff.uiuc.edu/~jongund
WWW: http://www.w3.org/wai/ua

Received on Friday, 9 March 2001 16:15:00 UTC