Map button on form to key on keyboard

M

MikeB

I have a simple form that I'm using to learn something about HTML and
JavaScript.

Can I associate a button on the form with a keyboard key so that when
the user presses the keyboard key the form thinks the button has been
clicked?

Background:
I'm learning HTML and JavaScript. We did a simple JavaScript that had
a button that would add the numbers in two input fields.

I then thought it would be nice to change the form (and the
JavaScript) to make a "real" calculator.http://fmechess.org/demo/
calculator.html

What I would like to do is to make the calculator sensitive to normal
presses of the keyboard keys, so that instead of clicking on the
buttons to enter a calcualtion, the user can simply type on the
keyboard. Is this possible?

Thanks.

PS. I hope this is the right ng to ask in, I got "booted" out of the
HTML ng for asking in there. :)
 
E

Evertjan.

MikeB wrote on 10 mei 2008 in comp.lang.javascript:
I have a simple form that I'm using to learn something about HTML and
JavaScript.

Can I associate a button on the form with a keyboard key so that when
the user presses the keyboard key the form thinks the button has been
clicked?

Yes you can, but not cross browser compatible.
Background:
I'm learning HTML and JavaScript.

Do HTML first, Javascript is another piece of cake.
We did a simple JavaScript that had
a button that would add the numbers in two input fields.

Who is "we", is this a school assignment?
I then thought it would be nice to change the form (and the
JavaScript) to make a "real" calculator.http://fmechess.org/demo/
calculator.html

Better come with som code that jou are imagining.
What I would like to do is to make the calculator sensitive to normal
presses of the keyboard keys, so that instead of clicking on the
buttons to enter a calcualtion, the user can simply type on the
keyboard. Is this possible?

Yes, see above.
Thanks.

PS. I hope this is the right ng to ask in, I got "booted" out of the
HTML ng for asking in there. :)

Are you sure it was not because you are not showing you did do any
reseach yourself before you asked?

Look for HTML 'accesskey' on Google.
 
M

MikeB

MikeB wrote on 10 mei 2008 in comp.lang.javascript:



Yes you can, but not cross browser compatible.

Well, thanks. I guess I *did* simply ask whether it can be done, not
*how *it can be done.
Do HTML first, Javascript is another piece of cake.

I'm just following the curriculum. We did a few weeks of basic HTML,
now we've moved on to incorporating JavaScript.
Who is "we", is this a school assignment?

No, it is what they call "continuing" or "adult" education. Done by
the school district, after hours, 7-9pm once a week. The instructor
hands out assignments, then the next week he hands out solutions. No
tests, no certificates.
Better come with som code that jou are imagining.

The url above (http://fmechess.org/demo/calculator.html is my work.
That's what I'm playing with. I didn't think it was practical to post
all that code (including the css here.
Yes, see above.



Are you sure it was not because you are not showing you did do any
reseach yourself before you asked?

Look for HTML 'accesskey' on Google.

Actually, I apologize. Here is the original thread in the HTML forum:

http://tinyurl.com/4q2yep

You may notice that in that I have mentioned that I have found and
tried using accesskey and that the results were erratic and
unpredictable.


Quoting from that thread:
 
T

Thomas 'PointedEars' Lahn

MikeB said:
I have a simple form that I'm using to learn something about HTML and
JavaScript.

Can I associate a button on the form with a keyboard key so that when
the user presses the keyboard key the form thinks the button has been
clicked?

Yes. However, in order to avoid messing with the user agents expected
behavior, this should be done with simple HTML only:

<input type="submit" value="OK" accesskey="o">

A key combination with the `O' key will be required then. What it is
exactly, depends on the GUI and the UA, but it will involve at least one
of Shift, Ctrl, Alt, Meta, and the `O' key.
Background:
I'm learning HTML and JavaScript. We did a simple JavaScript that had
a button that would add the numbers in two input fields.

I then thought it would be nice to change the form (and the
JavaScript) to make a "real" calculator.http://fmechess.org/demo/
calculator.html

In that case you should read on the keydown, keyup, and keypress events, and
event bubbling, though. The events have to be handled at an ancestor
element of the respective form control, while they bubble upwards from the
latter.

http://www.w3.org/TR/DOM-Level-2-Events/events.html
http://developer.mozilla.org/en/docs/DOM:event
What I would like to do is to make the calculator sensitive to normal
presses of the keyboard keys, so that instead of clicking on the
buttons to enter a calcualtion, the user can simply type on the
keyboard. Is this possible?

Yes, it is.
PS. I hope this is the right ng to ask in, I got "booted" out of the
HTML ng for asking in there. :)

This is strange, for HTML provides at least a partial solution to your problem.


PointedEars
 
M

MikeB

Yes. However, in order to avoid messing with the user agents expected
behavior, this should be done with simple HTML only:

<input type="submit" value="OK" accesskey="o">

A key combination with the `O' key will be required then. What it is
exactly, depends on the GUI and the UA, but it will involve at least one
of Shift, Ctrl, Alt, Meta, and the `O' key.



In that case you should read on the keydown, keyup, and keypress events, and
event bubbling, though. The events have to be handled at an ancestor
element of the respective form control, while they bubble upwards from the
latter.

http://www.w3.org/TR/DOM-Level-2-Events/events.htmlhttp://developer.mozilla.org/en/docs/DOM:event


Yes, it is.


This is strange, for HTML provides at least a partial solution to your problem.

Thank you! Thank you from the very bottom of my heart!
 
S

Steve Swift

Thomas said:
Yes. However, in order to avoid messing with the user agents expected
behavior, this should be done with simple HTML only:

<input type="submit" value="OK" accesskey="o">

I've started using this (mostly for my own benefit; it would
surprise/please me if anyone else had found the capability on any of my
pages).

I recommend two associated changes:

1. Keep records of what accesskeys you use across your pages, so buttons
with the same effect use the same key as far as possible. I would be
most upset to be using a series of "F" keys to go Forward only to
suddenly find that it meant "Format" on my last press.

2. Consider changing to <BUTTON TYPE=SUBMIT> because then you can
specify the label on your "OK" button as <U>O</U>K to give a visual clue
which key to use. **Beware of daft IE implementation though**
 
E

Evertjan.

MikeB wrote on 10 mei 2008 in comp.lang.javascript:
You may notice that in that I have mentioned that I have found and
tried using accesskey and that the results were erratic and
unpredictable.

I seem to remember that IE only allows Alt- a to z,
while IE-mobile [also?] allows Alt- 0 to 9.

The results however are not erratic and unpredictable,
they are according to specs of the individual browser.

The same would apply for FF, Opera, Safari, I suppose.
Reading the specs before calling something unpredictable.

The word "Erratic" I would preserve for inconsistent behavour even after
thorough testing of your programme on each targeted browser. Building for
cross browser compatibility is a teduous task.

Errare humanum, debuggere divinum.
 
M

Matthias Watermann

MikeB wrote on 10 mei 2008 in comp.lang.javascript:
You may notice that in that I have mentioned that I have found and
tried using accesskey and that the results were erratic and
unpredictable.

[...]
The word "Erratic" I would preserve for inconsistent behavour even after
thorough testing of your programme on each targeted browser. Building for
cross browser compatibility is a teduous task.

Unfortunately it's not "just" a (cross-)browser issue. There's something
else involved: the respective GUI. I stumbled over this problem some years
ago when some users where quite happy with the pages' access keys while
others complained that those access keys were misleading and wouldn't
work. I was able able to find two users with the very same browser, the
same OS and even the same GUI. However, what was working on one computer
didn't at the other's. After experimenting and changing the access keys
we finally figured out what the problem was: The GUI-setup allowed for
defining hotkeys for whatever purpose (like invoking programs or
switching desktops). And if such a GUI-based hotkey happens to be the
same as the one you're using (well, intend to use) on your web-page the
browser won't even get notified that the key in question was pressed
let alone have chance to react on it. And because every user is free to
define her/his favourite hotkeys there's no chance to use a set of
supposedly unused access keys for your web-page (even if there wouldn't
be the usual issues with browser incompatibilites).

To make a long story short: While access keys are a good idea in theory,
in practise there's no guarantee whatsoever that they will work anywhere
(except, may be, the developers own computer).

--
Matthias
/"\
\ / ASCII RIBBON CAMPAIGN - AGAINST HTML MAIL
X - AGAINST M$ ATTACHMENTS
/ \
 
E

Evertjan.

Matthias Watermann wrote on 11 mei 2008 in comp.lang.javascript:
MikeB wrote on 10 mei 2008 in comp.lang.javascript:
You may notice that in that I have mentioned that I have found and
tried using accesskey and that the results were erratic and
unpredictable.

[...]
The word "Erratic" I would preserve for inconsistent behavour even
after thorough testing of your programme on each targeted browser.
Building for cross browser compatibility is a teduous task.

Unfortunately it's not "just" a (cross-)browser issue. There's
something else involved: the respective GUI. I stumbled over this
problem some years ago when some users where quite happy with the
pages' access keys while others complained that those access keys were
misleading and wouldn't work. I was able able to find two users with
the very same browser, the same OS and even the same GUI. However,
what was working on one computer didn't at the other's. After
experimenting and changing the access keys we finally figured out what
the problem was: The GUI-setup allowed for defining hotkeys for
whatever purpose (like invoking programs or switching desktops). And
if such a GUI-based hotkey happens to be the same as the one you're
using (well, intend to use) on your web-page the browser won't even
get notified that the key in question was pressed let alone have
chance to react on it. And because every user is free to define
her/his favourite hotkeys there's no chance to use a set of supposedly
unused access keys for your web-page (even if there wouldn't be the
usual issues with browser incompatibilites).

To make a long story short: While access keys are a good idea in
theory, in practise there's no guarantee whatsoever that they will
work anywhere (except, may be, the developers own computer).

Good point, Matthias.

This leaves us with no other option than not to use the Alt and detect
the keys by the onkeydown or onkeypress of the page and also of the
relevant input fields and go from there.

To the newbee OP: do not follow this advice in your first year.
 
M

Matthias Watermann

[...]
Matthias Watermann wrote on 11 mei 2008 in comp.lang.javascript:
MikeB wrote on 10 mei 2008 in comp.lang.javascript:

You may notice that in that I have mentioned that I have found and
tried using accesskey and that the results were erratic and
unpredictable.

[...]
The word "Erratic" I would preserve for inconsistent behavour even
after thorough testing of your programme on each targeted browser.
Building for cross browser compatibility is a teduous task.

Unfortunately it's not "just" a (cross-)browser issue. There's
something else involved: the respective GUI. I stumbled over this
problem some years ago when some users where quite happy with the
pages' access keys while others complained that those access keys were
misleading and wouldn't work. I was able able to find two users with
the very same browser, the same OS and even the same GUI. However, what
was working on one computer didn't at the other's. After experimenting
and changing the access keys we finally figured out what the problem
was: The GUI-setup allowed for defining hotkeys for whatever purpose
(like invoking programs or switching desktops). And if such a GUI-based
hotkey happens to be the same as the one you're using (well, intend to
use) on your web-page the browser won't even get notified that the key
in question was pressed let alone have chance to react on it. And
because every user is free to define her/his favourite hotkeys there's
no chance to use a set of supposedly unused access keys for your
web-page (even if there wouldn't be the usual issues with browser
incompatibilites).

To make a long story short: While access keys are a good idea in
theory, in practise there's no guarantee whatsoever that they will work
anywhere (except, may be, the developers own computer).

Good point, Matthias.

This leaves us with no other option than not to use the Alt and detect
the keys by the onkeydown or onkeypress of the page and also of the
relevant input fields and go from there.

That won't work, I'm afraid. At least there's no guarantee. Just
consider the order of notifications when a key is pressed:

1. OS: usually here's nothing to be afraid of as far I'm aware.

2. GUI: here both the GUI's standard hotkeys as well as user defined
hotkeys are "eating" quite a few keys (each key with an arbitrary
combination of ALT/CTRL/SHIFT can be used); and there's at least GNOME,
KDE, OS/X and WinDos to consider, each of which in various versions.

3. Application: the browser itself as well as any browser plugin may
have hotkeys defined for their own purposes. How many browsers in how
many versions with how many plugins on how many platforms are you
prepared to check out? And how often will you repeat the tests to verify
the results with the respective then current version?

4. Web-page (incl. JavaScript): only those keys which are not used (i.e.
consumed) on a prior level will reach this point. If I configure my
GUI to - say - switch to desktop-1 on ALT-A your fine javascript will
wait for that very key 'till hell freezes over and the sun ceases to
shine or the user looses patience (whatever may happen first).

In consequence this means that you'd have to use key(combinations) that
are so unlikely as to be used already (say: SHIFT-CRTL-ALT-B for "back")
that it's hardly a comfort for the user to use them. And even if you
actually tried something like that, you still can't be sure that there
really is no OS or GUI or user or browser or plugin or ... that doesn't
consume you desired key(s) before the reach your page.

What I tried to say above was simply this: Offer your hotkeys (by means
of the "accesskey" tag attribute) and that's it.

Be happy, if your access keys are working as intended here and there.
But never rely on them. And: Don't waste a second of your valuable time
to implement something that will work by coincidence at best.

Do _not_ expect them to work anywhere. Do _not_ suggest to your readers
that they will work. Especially do _not_ write something like "just press
ALT-X to do this or CRTL-Y for that" on your page. The best possible
outcome for you would be to get complaints (more likely the readers will
just go away probably telling others to avoid your page because "it
doesn't work"). Don't rise your reader's expectations by announcements
which you can't reasonably fulfil (unless you're M$, that is).

That might sound discouraging. But, alas, sometimes it's better to know
what _not_ to do than to try something in vain.


--
Matthias
/"\
\ / ASCII RIBBON CAMPAIGN - AGAINST HTML MAIL
X - AGAINST M$ ATTACHMENTS
/ \
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,769
Messages
2,569,582
Members
45,059
Latest member
cryptoseoagencies

Latest Threads

Top