programmatically generated keyboard events initKeyEvent

[Marek Mand]

How to use generated keyboard events?

What I am trying here to do is in onkeyup event handler

http://www.hot.ee/idaliiga/braggart/createEventTest.htm

generate a (shift)TAB keydown so the focus would move to the
(previous/next ) input element.

--
marekmand

[Michael Winter]

On Wed, 03 Mar 2004 16:00:09 +0200, Marek Mand <ca********@mail.ee> wrote:

How to use generated keyboard events?
At this time, it is not possible (as far as I know) to emulate keyboard
events. In a later version of the Document Object Model (DOM) Event
specification[1], key events will be introduced. Even so, it will probably
be a while before browsers implement the new features. As Netscape
Communications Corporation have reportedly stopped development of the
Netscape browser, it is unlikely that it will ever support the new DOM
version.
What I am trying here to do is in onkeyup event handler

http://www.hot.ee/idaliiga/braggart/createEventTest.htm

generate a (shift)TAB keydown so the focus would move to the
(previous/next ) input element.

What you should be able to do here is detect the space and backspace key
presses, and call the focus() method on the next or previous control,
respectively. There is no actual need to simulate a tab press.

Mike
[1] I refer to DOM Level 3 Events, which has not yet become a W3C
Recommendation. Level 2 is the current version.

--
Michael Winter
M.******@blueyonder.co.invalid (replace ".invalid" with ".uk" to reply)

[Marek Mand]

Michael Winter wrote:

On Wed, 03 Mar 2004 16:00:09 +0200, Marek Mand <ca********@mail.ee> wrote:

How to use generated keyboard events?

At this time, it is not possible (as far as I know) to emulate keyboard
events.
http://groups.google.com/groups?q=in...ewin.ch&rnum=6
Is that person then delerious there??

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
Even so, it will probably be a while before browsers implement the new features.

Grins yea I wait the time ehen I can create mouse event mousemove
programmatically =D grins...

What I am trying here to do is in onkeyup event handler
http://www.hot.ee/idaliiga/braggart/createEventTest.htm
generate a (shift)TAB keydown so the focus would move to the
(previous/next ) input element.

There is no actual need to simulate a tab press.

I think it is.
How else would I know which is the previous or next form control ?

A form control doesnt have properties like
previousFormControl nextFormControl

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.

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?

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".

So what are the options?

[Michael Winter]

On Wed, 03 Mar 2004 17:22:34 +0200, Marek Mand <ca********@mail.ee> wrote:

[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 is no actual need to simulate a tab press.

I think it is.

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.
So what are the options?

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/...html#h-17.11.1

--
Michael Winter
M.******@blueyonder.co.invalid (replace ".invalid" with ".uk" to reply)

[Martin Honnen]

Michael Winter wrote:

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

Even worse, the W3C has finished working on W3C DOM Level 3 Events, they
have published a working group note
http://www.w3.org/TR/2003/NOTE-DOM-L...ents-20031107/
on Nov 7 2003 which means according to
http://www.w3.org/2003/06/Process-20...tr.html#WGNote
that the work on that topic has ended without reaching recommendation
status.
--

Martin Honnen
http://JavaScript.FAQTs.com/

[Marek Mand]

Michael Winter wrote:

Marek Mand <ca********@mail.ee> wrote:

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. 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.

[] I don't think that is a walking the tree isn't either,
necessarily, but it should be better supported than an unfinished
standard. [] Walking the tree isn't a hack. If done properly, it will be a very
successful method, but it will involve significant effort.

Hmm, so You propose the solution I was thinking of ;D
By having some elements not having the tabIndex specified ans some
having them specified it would be quite huge effort to walk all nodes
and get the order right. Apart from that there are browser preferences
"KEYBOARD NAVIGATION" in Mozilla IIRC which specify on what elements are
taken into TABORDER by browser at all. The DOM tree certainly doesnt
provide that info and there is no way to get the user preference under
normal circumstances. ;D

OK, but does anybody have such function that would implement the desired
functionality so I dont have to reinvent a wheel?
p.s. Thanks for the discussion, provided knowledge and opinions. =D

--
marekmand

[Michael Winter]

On Wed, 03 Mar 2004 18:39:08 +0100, Martin Honnen <ma*******@yahoo.de>
wrote:

Even worse, the W3C has finished working on W3C DOM Level 3 Events, they
have published a working group note
http://www.w3.org/TR/2003/NOTE-DOM-L...ents-20031107/
on Nov 7 2003 which means according to
http://www.w3.org/2003/06/Process-20...tr.html#WGNote
that the work on that topic has ended without reaching recommendation
status.

However, work on a report that has been given a Working Group Note status
may resume at any time. It depends why that status was imposed. After
looking through the last four years of the www-dom mailing list archives,
I couldn't find the point when the module became a Working Group Note.
However, it appears that the change was due to the number of issues
raised: errors, incompatibilities, clarifications, etc.

During my search, I did find that someone decided to spam the mailing list:

http://lists.w3.org/Archives/Public/...tDec/0110.html

What nerve!

Mike

--
Michael Winter
M.******@blueyonder.co.invalid (replace ".invalid" with ".uk" to reply)

[Michael Winter]

On Wed, 03 Mar 2004 19:50:44 +0200, Marek Mand <ca********@mail.ee> wrote:

Michael Winter wrote:

Marek Mand <ca********@mail.ee> wrote:

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. 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.

[]

> I don't think that is a walking the tree isn't either,
> necessarily, but it should be better supported than an unfinished
> standard.

You mis-quoted me there. My grammar isn't that bad. :P
[]

> Walking the tree isn't a hack. If done properly, it will be a very
> successful method, but it will involve significant effort.
Hmm, so You propose the solution I was thinking of ;D

I only propose it as some browsers seem to implement the methods that
would allow it. However, as those methods aren't standardised, I don't
recommend the approach. I discounted it initially because I didn't think
that browser developers would use an unfinished and, evidentally,
problematic standard.
By having some elements not having the tabIndex specified ans some
having them specified it would be quite huge effort to walk all nodes
and get the order right.
The only issue is that the specification doesn't say what value should
assumed when the tabindex isn't specified - it's left to the browser.
However, that would also mean it's up to you. I would probably use zero:
process the elements with a tabindex first, then the remaining elements in
order of appearance.
Apart from that there are browser preferences "KEYBOARD NAVIGATION"
in Mozilla IIRC which specify on what elements are taken into
TABORDER by browser at all.
In your example, it wouldn't matter. INPUT elements of type text are
*always* part of the tabbing order. Links can be excluded, as can buttons,
radio buttons, checkboxes and SELECT elements. Links are one group; the
other four are a second.
OK, but does anybody have such function that would implement the desired
functionality so I dont have to reinvent a wheel?
Not me, sorry.
p.s. Thanks for the discussion, provided knowledge and opinions. =D

You're very welcome.

Mike

--
Michael Winter
M.******@blueyonder.co.invalid (replace ".invalid" with ".uk" to reply)

[Nathan Sweet]

> How else would I know which is the previous or next form control ?

It is your form.

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.
This is not possible, unless you only want it to work in Mozilla
(which is what the link you posted is about).
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?

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".

So what are the options?

Make it Mozilla specific or you can use the "elements" collection on
the form element, which is "a collection, in source order, of all
controls in a given form". The elements collection is in the W3C DOM1
spec so I assume it works in all modern browsers.

http://msdn.microsoft.com/library/de...s/elements.asp

An example:

function keyPressed () {
// If moo is typed...
if ( window.event.srcElement.value != "moo" ) return;
// Figure the elements index.
var elements = document.getElementById( "someForm" ).elements;
for ( var elementIndex=0; elementIndex < elements.length;
elementIndex++ )
if ( elements[elementIndex] == window.event.srcElement )
break;
// Element not found.
if ( elementIndex == elements.length ) return;
// Otherwise, elementIndex is the index of the
window.event.srcElement.
// Focus the next element.
elementIndex++;
if ( elementIndex == elements.length ) elementIndex = 0;
elements[ elementIndex ].focus();
}

But normally tab and shit+tab look at the tabindex property of
elements on the page and tabs to the next one based on that order, not
just source order.

It seems to me that people wouldn't code something like this to be
applied generically to any form. It seems like it has a specific
application, and in that case you control the form and so can get the
exact functionality necessary.

[Marek Mand]

Michael Winter wrote:

On Wed, 03 Mar 2004 19:50:44 +0200, Marek Mand <ca********@mail.ee> wrote:

By having some elements not having the tabIndex specified ans some
having them specified it would be quite huge effort to walk all nodes
and get the order right.

The only issue is that the specification doesn't say what value should
assumed when the tabindex isn't specified - it's left to the browser.
However, that would also mean it's up to you. I would probably use zero:
process the elements with a tabindex first, then the remaining elements
in order of appearance.

Yes, and another of the shortcomings with this HTML doc referenced by
you is that it doesnt alloes only integers from 0 up to 32xxx and doesnt
seem to allow values such as -1 for tabIndex, which de facto specify
that the element doesnt take part of tabbing que.

Apart from that there are browser preferences "KEYBOARD NAVIGATION"
in Mozilla IIRC which specify on what elements are taken into
TABORDER by browser at all.

In your example, it wouldn't matter. INPUT elements of type text are
*always* part of the tabbing order. Links can be excluded, as can
buttons, radio buttons, checkboxes and SELECT elements. Links are one
group; the other four are a second.

True, but later on I was thinking of more generic function, which would
be applicable for links and inputs and textareas and selects.
Must do the hard labour all by myself ;D

--
marekmand