[whatwg] DOM-related and API-related feedback

[Ian Hickson]

On Wed, 1 Apr 2009, Kevin Field wrote:
> 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.

I once drafted something along these lines in the Web Controls draft:

   http://www.whatwg.org/specs/web-controls/current-work/#the-documentui

I haven't added this to HTML5 at this point (I'm concerned about feature 
creep, and I'd rather address this along with other editing problems all 
at once, probably in its own spec), but I think it's something we should 
definitely keep in mind.

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