Re: Comments on no-consensus priorities

a few footnotes
to follow up on what Paul Adelson said:

> 
> [Technique: 5.2.5] Keep track of the user's point of regard in each view
> and put it within the viewport when the user returns to the view.
> 
>      Native.

This technique requires a handshake.  The browser cannot do it
without some cooperation from the AT and vice versa.

> [Technique: 5.3.1] Alert the user when scripts are executed.
> 
>      How about: Give the user the option of being notified when scripts
>      are executed. [Native]

	How about: Give the user {quiet, alert, confirm} options
	governing script execution

> [Technique: 5.3.2] Provide information about document changes resulting
> from the execution of a script.
> 
>      I'm not clear on what the implications of this are, or how this
>      could be done. Should it say "Provide notification when a document
>      changes due to script execution"? Or is it supposed to give
>      specific info on what kind of change has taken place? If the
>      latter, there needs to be some clearer definition of what is
>      expected. Also, isn't this listed as Priority 3 in the Nov 12 doc?

	This blends into the above technique.  What matters is the
	impact of the script.  If the user wants to review/confirm
	prior to letting the script execute, it has to be caught
	prior to execution.  How to communicate what will happen
	is tougher.  On alert to offer the option of communicating
	what changed is easier.  There are plenty of tricks of the
	trade such as a transient select on the least document
	subtree enclosing the change.

> [Technique: 5.3.3] Allow users to be prompted before spawning a new
> window.
> 
>      Native.

	This is extending the "confirm" meta-control to all
	new-window transactions.  

> [Technique: 5.5.3] Provide a mechanism for designating the current table
> of a document.
> 
>      To be honest, I'm not sure what is meant by 'designate' in this
>      context.
> 

This has to do with the assumed state model.  Is there a
cross-platform definition of select, focus, etc. that we can
build on?

"Current table" probably combines some of the characteristics
of "select" and "system caret."  Need to worry about whether
the state of the tabbing cycle moves, too.  Likewise for
table cells.  Need to define the "current" state operationally.

Al

Received on Wednesday, 18 November 1998 13:25:31 UTC