[whatwg] DOM-related and API-related feedback

[Kevin Field]

On Sun Dec 28 03:38:07 PST 2008, Ian Hickson wrote:
>
> On Sun, 8 Jun 2008, Ojan Vafai wrote:
> > 
> > I can speak to the first (getNextFocusableElement). One case I have 
> > hit 
> > where this would be useful is a designMode iframe (in this case a 
> > rich-text editor). I wanted tab to go to the next focusable 
> > element, 
> > which was a different element depending on the context the editor 
> > is 
> > embedded in. There's currently no way to do that.
> 
> It seems like this is something that should be left up to the user 
> agent. 
> After all, how is the Web page to know which key binding moves the 
> focus 
> normally anyway?
> 
> If we were to provide this it seems what we'd have to do is provide 
> an API 
> that actually moves the focus (e.g. provide a focusNextElement() 
> method 
> and a focusPreviousElemnt() method), since the next focusable item 
> might 
> not even have a DOM node (e.g. the location bar) or it might be in 
> another 
> origin. But then what if the user agent doesn't do things using a 
> cycle 
> but instead uses directional focus management, like many phones?

I'm currently working on a UI that I intend to be fully usable via 
keyboard or mouse.  When an element is given focus, a mouse-usable UI 
is generated, but the focused element also accepts keystrokes.  It 
appears to be currently very difficult to have the element give its 
focus over to the next available focusable element when the user clicks 
something in the mouse-usable UI.  So I'm not replacing tab or whatever 
the keybinding might be, but I do want a click in one area to be 
followed by a simulated tab (or equivalent) keypress.  This is an 
important use case for me.

I propose extending the blur() function to act like history.go(): 
element.blur(-1) would act like element.focus() plus a shift + tab (or 
equivalent) keypress, and element.blur(1) would act like 
element.focus() plus a tab (or equivalent) keypress.

Your final question made me stop and think, but in the end, "6.5.1 
Sequential focus navigation" and the tabindex attribute already exist.  
This should still work.  Developers targeting phone platforms would 
simply not make use of this function, and in any case, phone users 
would still have their directional focus management available unless 
the developer was malicious, in which case she or he could just abuse 
element.focus() or other existant technologies as-is.

( A less professional rant on this is available here for context: http://kevinjamesfield.blogspot.com/2009/04/manual-focus-management-woes.html 
woes.html 
)