[a person using initKeyEvent()]
Is that person then delerious there??
Somewhat, yes.
Development of DOM Level 3 began a while ago (the earliest date I could
find was in 2000), but it has not been finished. Whilst the Core module
(and two others) is a Proposed Recommendation, the Events module isn't
even that far along so I would say that using it, especially relying on
it, is a bad idea.
initKeyEvent() is a method introduced in the DOM Level 3 Events Working
Draft, written in 2000. The latest version of the Events module written
last year has no such method: it has been renamed to initKeyboardEvent().
When the Events module finally becomes a Recommendation, it will probably
use the latter. That method call you cited might be unsupported in future:
the implementation it relies upon does, after all, used an unfinished
document as its specification.
KeyEvent, and therefore initKeyEvent(), has been totally removed from the
latest edition. [guess] I think the change occurred due to the presence of
a KeyEvent class existing in Java. [/guess].
In a later version of the Document Object Model (DOM) Event
specification[1], key events will be introduced.
I read that too, but whats the point of mentioning that in the
documentation in first place... ;D
It's an obvious omission in the specification. Other event types have been
catered for, but not those fired from keyboard input.
[snip]
There's no *need*, but it would be easier.
How else would I know which is the previous or next form control ?
By examining the DOM tree, determining the tab order, and giving focus
appropriately.
A form control doesnt have properties like
previousFormControl nextFormControl
No they don't, but Node interfaces have nextSibling and previousSibling
properties. They won't work directly as you'd like, but moving through
sibling after sibling, checking the element type as you go, will produce
the same effect.
The whole point of why I wanted to 'stuff the keyboard buffer' with tab
char is that I wanted to let the browser do the underlying work of
moving the input focus and not me.
I understand that but I don't think that is a reliable option at the
moment. Walking the tree isn't either, necessarily, but it should be
better supported than an unfinished standard.
If I have no fixed ID attributes and controller object that descibes the
relation and order of references of input elements how would I know
which is previous and which is next?
The same way the browser does. Look up the tabindex attribute (URL below)
in the HTML 4.01 Specification. It describes the tab order and how it is
determined.
I dont think that as a ugly hack walking the tree and making descisions
upon it guarantees me the "natural order of form elements navigation".
Walking the tree isn't a hack. If done properly, it will be a very
successful method, but it will involve significant effort.
As I see them:
- Use initKeyEvent() and initKeyboardEvent() to simulate a tab press,
using feature detection to determine support.
- Walk the tree and, using the tab order defined by the HTML
Specification, set focus yourself.
The first requires the least effort, but is the most unreliable. The
second option is the reverse. Which one you use is your choice.
Mike
tabindex attribute:
http://www.w3.org/TR/html4/interact/forms.html#h-17.11.1