Shift key detection on input

Csaba Gabor · Mar 23, 2006

I'd like to detect the shift key when a button is "clicked" in
Firefox/Mozilla. If the button is clicked with the mouse, no problem.
However, if the onclick event is keyboard originated, then my method is
not working. Same thing for SELECT elements.

The simple web page below shows the issue. Click with the mouse while
holding down the shift key, and the Shift key's status registers.
However, use Shift+Alt+o, or either (while the button has focus)
Shift+Space or Shift+Enter to kick off the onClick event and the shift
key is not detected. Works fine with IE 6 on my Win XP Pro.

<html><body><title>onClick and Shift key detection</title></head>
<body>
<button type=button accessKey=i
onclick="bclick(this,event)">on<u>C</u>lick</button>
  
<button type=button accessKey=a
onactivate="aclick(this,event)">on<u>A</u>ctivate</button>

<script type='text/javascript'>
function bclick(ctl,evt) {
evt = evt || window.event;
if (evt.shiftKey) alert("Shift key was pressed");
else alert("Shift key not detected");
}
function aclick(ctl, evt) {
/* evidently not working - see

http://www.w3.org/TR/1999/WD-DOM-Level-2-19990923/events.html#Events-UIEvent
*/
alert(evt.detail);
}
</script>
</body>
</html>

Any suggestions or comments?
Csaba Gabor from Vienna

Thomas 'PointedEars' Lahn · Mar 23, 2006

Csaba said:
I'd like to detect the shift key when a button is "clicked" in
Firefox/Mozilla. If the button is clicked with the mouse, no problem.
However, if the onclick event is keyboard originated, then my method is
not working. Same thing for SELECT elements.

The simple web page below shows the issue. Click with the mouse while
holding down the shift key, and the Shift key's status registers.
However, use Shift+Alt+o, or either (while the button has focus)

Shift+Alt+O could trigger another application as well. Shift+Alt+C triggers
a new KNotes note here, for example.

But what should that trigger in your case anyway? You have no accesskey="o"
anywhere.

Shift+Space or Shift+Enter to kick off the onClick event and the shift
key is not detected. Works fine with IE 6 on my Win XP Pro.

<html><body><title>onClick and Shift key detection</title></head>

Your markup is not Valid. Scripts operating on or within not Valid markup
are unlikely to work properly. <URL:http://validator.w3.org/>

Probably someone told you this before.

<body>
<button type=button accessKey=i

All attribute values should be quoted, no matter the value.

onclick="bclick(this,event)">on<u>C</u>lick</button>
  

Should you not underline the `i' if the accessibility key is "i"?
Ahhh -- but Alt+i triggers the history context menu with the Tab list here.

<button type=button accessKey=a
onactivate="aclick(this,event)">on<u>A</u>ctivate</button>

This is an element not defined before HTML 4.0, so it is even more
imperative that you declare the document type. However, no HTML
element has an `onactivate' attribute.

<script type='text/javascript'>
function bclick(ctl,evt) {
evt = evt || window.event;

if (!evt) evt = window.event;
if (evt)
{

if (evt.shiftKey) alert("Shift key was pressed");
else alert("Shift key not detected");

It would be better if you displayed the value of evt.shiftKey, because
it may be `undefined', which also evaluates to `false' in a boolean
expression.

}
function aclick(ctl, evt) {
/* evidently not working - see

http://www.w3.org/TR/1999/WD-DOM-Level-2-19990923/events.html#Events-UIEvent
^^
Working Drafts MUST NOT be used as reference material. Use this instead:

*/
alert(evt.detail);

However, I fail to see the relevance to your problem:

| The `detail' attribute inherited from UIEvent indicates the number of
| times a mouse button has been pressed and released over the same screen
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
| location during a user action. The attribute value is 1 when the user
| begins this action and increments by 1 for each full sequence of pressing
| and releasing. If the user moves the mouse between the mousedown and
| mouseup the value will be set to 0, indicating that no click is occurring.

evt.detail works in Firefox 1.5.0.1/Linux -- for _mouse_ events.

Furthermore, the `onclick' code is is not added as event listener to the
target element using one of the W3C DOM Level 2 Events methods, so it is
not surprising that the behavior is different that you expect. However,
even if you do use addEventListener() it does not work as you expect.
The obvious reason is that `click' is specified as a mouse event, but
you trigger its intrinsic event handler with a keyboard event.

There is no DOM standard for keyboard events yet; there is a Working Draft
of W3C DOM Level 3 Events that includes the first time ever. So it is also
not surprising that Gecko-based and IE-based UAs work differently here.

[...]
Any suggestions or comments?

[x] done

PointedEars

Csaba Gabor · Mar 23, 2006

Thomas said:
Shift+Alt+O could trigger another application as well. Shift+Alt+C triggers
a new KNotes note here, for example.
....

Your markup is not Valid. Scripts operating on or within not Valid markup

Sigh. There were several errors in the offered page, including <body>
appearing twice. Sorry about that. It was late and my transference
was poor. That should have been accessKey=c and Shift+Alt+c in the
text. Here's a proper page I have the beef with:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html><head>
<meta http-equiv="content-type" content="text/html;charset=iso-8859-1">

<title>onClick and Shift key detection</title></head>
<body>
<script type='text/javascript'>
function bclick(ctl,evt) {
evt = evt || window.event;
if (evt.shiftKey) alert("Shift key was pressed");
else alert("Shift key not detected");
}
</script>
<button type=button accessKey=c
onclick="bclick(this,event)">on<u>C</u>lick</button>

are unlikely to work properly. <URL:http://validator.w3.org/>

Not in my experience. If we define working properly as performing in
the way that the author believes it should. Appears to me most of the
pages I visit, including biggies such as google.com, amazon.com,
chase.com, and wired.com do not have a DOCTYPE at the top and yet these
pages work as (I think) they should in the browsers I use, FF and IE.
Browsers tend to be quite forgiving about sloppy markup, not that that
justifies it.

At the same time, unless possibly dealing with layout issues, I can't
think that that DOCTYPE or <meta ... content...> has EVER affected me
in the pages I've written. Except that as I recall, the validator used
to pout when <meta ... content...> was not in my pages and now, lo and
behold, it is no longer necessary. Thus, the motivation is really low
to install that terrifically ugly line at the top of my pages.

This is an element not defined before HTML 4.0, so it is even more
imperative that you declare the document type. However, no HTML
element has an `onactivate' attribute.

This is another thing that I forgot to mention. Turns out that IE 6
has an onactivate and it fires when button gets focus - I didn't look
into it. And detail there is not defined. This differs markedly from
what I read the intention of onactivate to be on the page I referenced.

http://www.w3.org/TR/1999/WD-DOM-Level-2-19990923/events.html#Events-UIEvent
^^
Working Drafts MUST NOT be used as reference material. Use this instead:

<URL:http://www.w3.org/TR/DOM-Level-2/events.html#Events-UIEvent>
Thanks

However, I fail to see the relevance to your problem:

| The `detail' attribute inherited from UIEvent indicates the number of
| times a mouse button has been pressed and released over the same screen
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
| location during a user action. The attribute value is 1 when the user

Yes, but detail in that working draft for onactivate said:
A numerical argument is provided to give an indication of the type of
activation that occurs: 1 for a simple activation (e.g. a simple click
or Enter), 2 for hyperactivation (for instance a double click or Shift
Enter).

From that I imagined that it might possibly be related to Shift, it it

worked at all. That was the only reason for the inclusion of the 2nd
button. But since we're on the topic, I put in an event listener for
DOMActivate and it fired when the button was clicked, but event.detail
was undefined for it.

....

Furthermore, the `onclick' code is is not added as event listener to the
target element using one of the W3C DOM Level 2 Events methods, so it is
not surprising that the behavior is different that you expect. However,
even if you do use addEventListener() it does not work as you expect.

I don't understand this - I must be missing your meaning. Are you
saying that putting onclick="..." in an element's tag is not
sanctioned?

The obvious reason is that `click' is specified as a mouse event, but
you trigger its intrinsic event handler with a keyboard event.

Ah. The meat. About shiftKey (of type boolean, readonly) it says:
Used to indicate whether the 'shift' key was depressed during the
firing of the event.

It is not qualified with "if due to a mouse click". If the event
fires, shiftKey should be set with the shiftKey's status at the time
that event fired, regardless of why the event fired.

There is no DOM standard for keyboard events yet; there is a Working Draft
of W3C DOM Level 3 Events that includes the first time ever. So it is also
not surprising that Gecko-based and IE-based UAs work differently here.

Thanks: http://www.w3.org/TR/DOM-Level-3-Events/

Csaba

Thomas 'PointedEars' Lahn · Mar 23, 2006

Csaba said:
Not in my experience. If we define working properly as performing in
the way that the author believes it should.

But where, when, and for how long?

Appears to me most of the pages I visit, including biggies such as
google.com, amazon.com, chase.com, and wired.com do not have a DOCTYPE
at the top and yet these pages work as (I think) they should in the
browsers I use, FF and IE. ^^^^^^^^^^^^^^^^^^^^^^^^^^
Browsers tend to be quite forgiving about sloppy markup,

^^^^^^^^^^
You see?

not that that justifies it.
Exactly.

[...]

<button type=button accessKey=a
onactivate="aclick(this,event)">on<u>A</u>ctivate</button>

Click to expand...

This is an element not defined before HTML 4.0, so it is even more
imperative that you declare the document type. However, no HTML
element has an `onactivate' attribute.

Click to expand...

This is another thing that I forgot to mention. Turns out that IE 6
has an onactivate and it fires when button gets focus - I didn't look
into it. And detail there is not defined. This differs markedly from
what I read the intention of onactivate to be on the page I referenced.

What IE does or does not define is irrelevant regarding interoperability.

http://www.w3.org/TR/1999/WD-DOM-Level-2-19990923/events.html#Events-UIEvent
^^
Working Drafts MUST NOT be used as reference material. Use this instead: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
<URL:http://www.w3.org/TR/DOM-Level-2/events.html#Events-UIEvent>
Thanks

However, I fail to see the relevance to your problem:

| The `detail' attribute inherited from UIEvent indicates the number of
| times a mouse button has been pressed and released over the same screen
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
| location during a user action. The attribute value is 1 when the user

Click to expand...

Yes, but detail in that working draft for onactivate said: [...]

Whatever it says is not relevant /because/ it is only a _Working Draft_.

I put in an event listener for DOMActivate and it fired when the button
was clicked, but event.detail was undefined for it.

The UIEvent::view property, and the UIEvent::initUIEvent() method are
not supported, too. It would appear that the Gecko DOM does not fully
implement the User Interface event module and the UIEvent interface of
W3C DOM Level 2 Events. That would be a bug either way, since its
document.implementation.hasFeature("UIEvents", "2.0") yields `true'.

I don't understand this - I must be missing your meaning. Are you
saying that putting onclick="..." in an element's tag is not
sanctioned?

It is sanctioned; `onclick' is an intrinsic event handler attribute in
(X)HTML. However, you are expecting a keyboard event, when it triggers
an event handler for a mouse event (click) that is attached to that
attribute, to work like a mouse event. Shift key-press detection works
with an intrinsic keyboard event handler, like `onkeypress', in Firefox
1.5.0.1/Linux, where it would appear that Gecko 1.8 implements (at least
partially) the Keyboard Event module and the KeyboardEvent interface of
the current W3C DOM Level 3 Events Working Group Note (see below).

The obvious reason is that `click' is specified as a mouse event, but
you trigger its intrinsic event handler with a keyboard event.

Click to expand...

Ah. The meat. About shiftKey (of type boolean, readonly) it says:
Used to indicate whether the 'shift' key was depressed during the
firing of the event.

It is not qualified with "if due to a mouse click". [...]

| // Introduced in DOM Level 2:
| interface MouseEvent : UIEvent {
| [...]
| readonly attribute boolean shiftKey;

If the event fires, shiftKey should be set with the shiftKey's status
at the time that event fired, regardless of why the event fired.

No. It is a mouse event, but you triggered its intrinsic event handler
with a keyboard event. Neither are keyboard events specified yet, nor is
specified how event listeners for mouse events should work if triggered
by a keyboard event.

And I have showed that your expectations about the Shift key are not
practical in web browsers, as the Shift key in combination with the Alt
key and/or other keys usually triggers other features or applications in
graphical environments. So it is at least unwise to rely on that key
combination for a Web document except of one in a controlled environment.

Thanks: http://www.w3.org/TR/DOM-Level-3-Events/

Yes, it is still a Working Group Note, not a Recommendation:

| This document contains the Document Object Model Level 3 Events
| specification and is a W3C Working Group Note. It is based on the
| feedback during the Last Call period. The W3C DOM Working Group
| participants do not expect to provide interoperable implementations
| of this module.
| [...]
| Publication as a Working Group Note does not imply endorsement by the
| W3C Membership. This is a draft document and may be updated, replaced
| or obsoleted by other documents at any time.

PointedEars

Csaba Gabor · Apr 23, 2006

Thomas said:
What IE does or does not define is irrelevant regarding interoperability.

On the contrary, IE's definitions are highly relevant, especially where
interoperability is concerned. Furthermore, when there is not a clear
standard defined, Mozilla looks to IE and very often will implement the
same thing exactly because IE has already defined it.

}
function aclick(ctl, evt) {
/* evidently not working - see

http://www.w3.org/TR/1999/WD-DOM-Level-2-19990923/events.html#Events-UIEvent
^^
Working Drafts MUST NOT be used as reference material. Use this instead: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
<URL:http://www.w3.org/TR/DOM-Level-2/events.html#Events-UIEvent> Thanks

However, I fail to see the relevance to your problem:

| The `detail' attribute inherited from UIEvent indicates the number of
| times a mouse button has been pressed and released over the same screen
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
| location during a user action. The attribute value is 1 when the user

Click to expand...

Yes, but detail in that working draft for onactivate said: [...]

Click to expand...

Whatever it says is not relevant /because/ it is only a _Working Draft_.

There's that word again. Relevancy is always in relationship to
something else. You said Working Drafts MUST NOT be used as reference
material. Well and good, I didn't look carefully enough.
Then you continued on saying you failed to see the relevance to my problem
thus referencing it yourself, by implication. So I explained how it
WOULD HAVE BEEN been relevant, rather than making any claim about it
applying now. So what it says may not be relevant to the issue,
but it is very relevant to my thinking about the problem.
Which IS relevant.

....

The obvious reason is that `click' is specified as a mouse event, but
you trigger its intrinsic event handler with a keyboard event.

Click to expand...

Ah. The meat. About shiftKey (of type boolean, readonly) it says:
Used to indicate whether the 'shift' key was depressed during the
firing of the event.

It is not qualified with "if due to a mouse click". [...]

Click to expand...

| // Introduced in DOM Level 2:
| interface MouseEvent : UIEvent {
| [...]
| readonly attribute boolean shiftKey;

If the event fires, shiftKey should be set with the shiftKey's status
at the time that event fired, regardless of why the event fired.

Click to expand...

No.

Evidently a gratuitous no.

It is a mouse event, but you triggered its intrinsic event handler
with a keyboard event. Neither are keyboard events specified yet, nor is
specified how event listeners for mouse events should work if triggered
by a keyboard event.

On the contrary, I pointed it out in my previous post.
I have not read anywhere in the docs that say that the mouse events may
only fire when the mouse is being used. That would be untrue, anyway,
since a click fires when the space bar is depressed when a button has
focus. Furthermore, the click event states certain circumstances under
which it will happen, and does not say anything about when it will not
happen.

All this does not remove the burden of obligation, according to the
spec, of providing a shiftKey status, regardless of the reason for
which the event fired.

http://www.w3.org/TR/DOM-Level-2-Events/events.html#Events-eventgroupings-mouseevents

And I have showed that your expectations about the Shift key are not
practical in web browsers,

Hogwash. You have shown very little about my expectations indeed.
Firing off a gratuitous "No" and a few irrelevant it's not relevants
does not mean that my expectations are not reasonable or practical.
That's the problem with saying "No, you can't do it that way" -
it's not very constructive because there may be other ways.
In fact, it is possible to determine the shift key state by using
a combination of onkeydown, onkeyup, onclick, ... to keep track of
its state for those situations when it is not supplied in the event
object, which is far messier than it should be.

as the Shift key in combination with the Alt
key and/or other keys usually triggers other features or applications in
graphical environments.

Well, I would only be interested in the shift key state when
my event handler fires.

So it is at least unwise to rely on that key
combination for a Web document except of one in a controlled environment.

Huh? I'm not relying on a specific key combination. I just want
to know about the shift key.

Thanks: http://www.w3.org/TR/DOM-Level-3-Events/

Click to expand...

Yes, it is still a Working Group Note, not a Recommendation:

| This document contains the Document Object Model Level 3 Events
| specification and is a W3C Working Group Note. It is based on the
| feedback during the Last Call period. The W3C DOM Working Group
| participants do not expect to provide interoperable implementations
| of this module.
| [...]
| Publication as a Working Group Note does not imply endorsement by the
| W3C Membership. This is a draft document and may be updated, replaced
| or obsoleted by other documents at any time.

Thomas 'PointedEars' Lahn · Apr 23, 2006

Csaba said:
On the contrary, IE's definitions are highly relevant, especially where
interoperability is concerned.

No, it is not. The above markup is not Valid.

Furthermore, when there is not a clear standard defined, Mozilla looks to
IE and very often will implement the same thing exactly because IE has
already defined it.

There are not only Geckos and IEs.

Your calendar is off by exactly one month, BTW.

PointedEars

Randy Webb · Apr 24, 2006

Csaba Gabor said the following on 4/23/2006 12:43 PM:

Thomas 'PointedEars' Lahn wrote:

Hogwash. You have shown very little about my expectations indeed.
Firing off a gratuitous "No" and a few irrelevant it's not relevants
does not mean that my expectations are not reasonable or practical.

Welcome to Thomas' world of thinking.

That's the problem with saying "No, you can't do it that way" -
it's not very constructive because there may be other ways.
In fact, it is possible to determine the shift key state by using
a combination of onkeydown, onkeyup, onclick, ... to keep track of
its state for those situations when it is not supplied in the event
object, which is far messier than it should be.

I am not sure I agree with that. But, I have not read this entire
thread. Have you come up with a way to know its "state" when the page is
loaded? Whether the CapsLock key is locked or not will affect the Shift
Key State.

Csaba Gabor · May 2, 2006

Randy said:
Csaba Gabor said the following on 4/23/2006 about Lahn no mongering:

I am not sure I agree with that. But, I have not read this entire
thread. Have you come up with a way to know its "state" when the page is
loaded?

No I have not. But for my purposes I am interested in knowing the
state of the shift key upon a (button) click event firing, and for that
it is sufficient: a click is either generated by an actual mouse click
(in which case I can know the shift status from the event object) or
some key on the keyboard must be pressed in which case I get keydown
and keypress events that I must process to know the shift key state.
There are other scenarios (with pulling down select elements, if I
remember correctly) where this approach might not be sufficient because
some events get 'eaten'.

Whether the CapsLock key is locked or not will affect the Shift Key State.

Could you give an example here? As far as I know, it's not the case.
CapsLock affects how keystrokes get translated to characters, but it
doesn't affect the Shift Key State. Thus, if you have CapsLock on and
press a q, the character generated is Q, but event.shiftKey will be
false. Conversely, if you then press Shift+q, you'll get a q, but
event.shiftKey will be true. You can check it out at:
https://bugzilla.mozilla.org/attachment.cgi?id=219883
(part of https://bugzilla.mozilla.org/show_bug.cgi?id=335538)

Csaba

The rest of this is just nother PointedEars INC post with factual
error.
I wonder if he thinks it's still April.

redirect input to accelerator (accessKey)	1	Mar 23, 2006
Messages don't show on the website, only stores in Firestore Database	1	Jan 22, 2023
smooth movement using SHIFT and ARROW keys	4	Aug 1, 2007
All CRUD operations work except POST. Why?	2	May 28, 2023
Need help with stripe payment	0	Oct 2, 2021
Capture ENTER in input field	5	Mar 1, 2008
Return / Enter handling on Textbox	1	Aug 14, 2006
How to avoid opening a new window with the shift key?	52	May 17, 2004

Shift key detection on input

Csaba Gabor

Thomas 'PointedEars' Lahn

Csaba Gabor

Thomas 'PointedEars' Lahn

Csaba Gabor

Thomas 'PointedEars' Lahn

Randy Webb

Csaba Gabor

Ask a Question

Similar Threads

Members online

Forum statistics

Latest Threads