[whatwg] Focus management

On Fri, 4 May 2007, Simon Fraser wrote:
>
> Some web applications may need more control over focus than is offered 
> by the existing focus management proposal: 
> <http://www.whatwg.org/specs/web-apps/current-work/#focus>
> 
> Specifically, it's hard to write JavaScript that has more explicit 
> control over focus changes. Functionality that is missing (but often 
> included in native UI toolkits) includes:
> 
> * Focus chain queries
>     need the ability to ask the document what the next/previous focusable
>     element is from a given element, or from null (first/last focusable
>     element).
> 
> * Is element focusable
>     need to be able to ask an element if it can take focus. Focusability is
>     currently some function of element type, tabindex, visibility,
>     contentEditability, UA preferenes etc, and it's hard to write JS
>     that computes this.
> 
> * Explicit advance/rewind focus
>     need to be able to move focus to the next/previous focusable
>     element without having explicit knowledge of what the next
>     element is (this mirrors what happens when the user hits the Tab
>     or Shift-Tab keys).
> 
>     (If nextFocus()/previousFocus() are available, this could be achieved with
>         document.nextFocus(document.activeElement).focus(),
>      but that seems a little long-winded.)

Could you elaborate on the use cases for these? I'd rather not add these 
features just because other environments have them, but if there are good 
reasons to have them, I'd naturally be happy to add them.


> In addition, I'd like to see a few clarifications in the "Focus management"
> section of the Web Applications draft:
> 
> * What does focus() do on an unfocusable element? Does the previously
>   focused element remain focused?

This is now clarified, hopefully.


> * document.activeElement has some ambiguities:
>     - Is it valid when the window does not have focus?

Does this sentence in an earlier sentence answer this unambigiously?:

# Which element(s) within a top-level browsing context currently has focus 
# must be independent of whether or not the top-level browsing context 
# itself has the system focus.


>     - IE has a setActive() method that changes the activeElement, but
>         does not change the focus. So the activeElement is not always
>         the focused element.

Should we specify setActive()?

Does it just set which element would be focused if the document were to 
get focus?

As defined, activeElement just returns the element _within the document_ 
that is focued, that might not be the element with system focus if another 
document has the system focus.


> * how does display: none or visibility: hidden interact with focus?
>     - can non-rendered elements be focused?

No (this is explicit now, though it could probably be clearer).


>     - if a focused element becomes unrendered, does focus move to the
>       next focusable element?

No (this is implicit in that it becomes an unfocusable element and thus 
can't be focused, but the focus doesn't go anywhere in particular, 
there's just not focused element).


> Finally I'd like to see some discussion around focus() and window activation.
> window.focus() obviously (and annoyingly) activates the window, but should
> focussing an element inside a window raise the window? What happens if
> that window is a hidden tab in a tabbed browser?

window.focus() isn't in HTML5 as there doesn't appear to be a valid use 
case for it and it is too abusable, and thus shouldn't be supported. If 
pages depend on it being supported we could make it a no-op, I guess.

Focusing an element inside a window should raise the window or hidden tab 
at the UA's discretion. I don't know that there's anything we need to 
explicitly say about that.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Tuesday, 3 June 2008 04:19:04 UTC