[whatwg] DOM-related and API-related feedback
kev at brantaero.com
Wed Apr 1 12:00:23 PDT 2009
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
> After all, how is the Web page to know which key binding moves the
> 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()
> and a focusPreviousElemnt() method), since the next focusable item
> not even have a DOM node (e.g. the location bar) or it might be in
> origin. But then what if the user agent doesn't do things using a
> 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
More information about the whatwg