Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Javascript > Shift key detection on input

Reply
Thread Tools

Shift key detection on input

 
 
Csaba Gabor
Guest
Posts: n/a
 
      03-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>
&nbsp;&nbsp;
<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-Lev...Events-UIEvent
*/
alert(evt.detail);
}
</script>
</body>
</html>


Any suggestions or comments?
Csaba Gabor from Vienna

 
Reply With Quote
 
 
 
 
Thomas 'PointedEars' Lahn
Guest
Posts: n/a
 
      03-23-2006
Csaba Gabor wrote:

> 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>
> &nbsp;&nbsp;


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

> */
> 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
 
Reply With Quote
 
 
 
 
Csaba Gabor
Guest
Posts: n/a
 
      03-23-2006
Thomas 'PointedEars' Lahn wrote:
> Csaba Gabor wrote:
> > 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.


....

> 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>
</body></html>

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

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


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.

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

> http://www.w3.org/TR/1999/WD-DOM-Lev...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

 
Reply With Quote
 
Thomas 'PointedEars' Lahn
Guest
Posts: n/a
 
      03-23-2006
Csaba Gabor wrote:

> Thomas 'PointedEars' Lahn wrote:
>> Csaba Gabor wrote:
>> > 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.

>
> ...
>
>> Your markup is not Valid. Scripts operating on or within not Valid
>> markup 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.


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>

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


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

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

>>

http://www.w3.org/TR/1999/WD-DOM-Lev...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: [...]


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

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


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.

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

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


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
 
Reply With Quote
 
Csaba Gabor
Guest
Posts: n/a
 
      04-23-2006
Thomas 'PointedEars' Lahn wrote:
> Csaba Gabor wrote:
>
>> Thomas 'PointedEars' Lahn wrote:
>>> Csaba Gabor wrote:
>>>> 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.

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

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


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-Lev...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: [...]

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


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


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

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

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

 
Reply With Quote
 
Thomas 'PointedEars' Lahn
Guest
Posts: n/a
 
      04-23-2006
Csaba Gabor wrote:

> Thomas 'PointedEars' Lahn wrote:
>> Csaba Gabor wrote:
>>> Thomas 'PointedEars' Lahn wrote:
>>>> Csaba Gabor wrote:
>>>>> <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.
>>> 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.

>
> 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
 
Reply With Quote
 
Randy Webb
Guest
Posts: n/a
 
      04-24-2006
Csaba Gabor said the following on 4/23/2006 12:43 PM:
> Thomas 'PointedEars' Lahn wrote:


<snip>

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


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.

--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
 
Reply With Quote
 
Csaba Gabor
Guest
Posts: n/a
 
      05-02-2006
Randy Webb wrote:
> Csaba Gabor said the following on 4/23/2006 about Lahn no mongering:
> > 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?


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.


Thomas 'PointedEars' Lahn wrote:
> Csaba Gabor wrote:
>
> > Thomas 'PointedEars' Lahn wrote:
> >> Csaba Gabor wrote:
> >>> Thomas 'PointedEars' Lahn wrote:
> >>>> Csaba Gabor wrote:
> >>>>> <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.
> >>> 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.

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


 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Java left shift and right shift operators. Sanny Java 38 04-29-2011 10:02 PM
what "shift" does, if not "$_ = shift;" ? devphylosoff Perl Misc 3 12-04-2007 12:27 AM
Left Shift / Right Shift Operators Santosh Nayak C Programming 16 11-30-2006 05:10 PM
Shift - byte[] buf shift Roberto Gallo Java 3 01-27-2004 04:26 PM
left shift then right shift an unsigned int Wenjie C++ 3 07-11-2003 08:22 PM



Advertisments