Shift key detection on input

Discussion in 'Javascript' started by Csaba Gabor, Mar 23, 2006.

  1. Csaba  Gabor

    Csaba Gabor Guest

    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-Level-2-19990923/events.html#Events-UIEvent
    */
    alert(evt.detail);
    }
    </script>
    </body>
    </html>


    Any suggestions or comments?
    Csaba Gabor from Vienna
     
    Csaba Gabor, Mar 23, 2006
    #1
    1. Advertising

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

    > */
    > 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
     
    Thomas 'PointedEars' Lahn, Mar 23, 2006
    #2
    1. Advertising

  3. Csaba  Gabor

    Csaba Gabor Guest

    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-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
     
    Csaba Gabor, Mar 23, 2006
    #3
  4. 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-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: [...]


    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
     
    Thomas 'PointedEars' Lahn, Mar 23, 2006
    #4
  5. Csaba  Gabor

    Csaba Gabor Guest

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

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

    >>> 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.
     
    Csaba Gabor, Apr 23, 2006
    #5
  6. 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
     
    Thomas 'PointedEars' Lahn, Apr 23, 2006
    #6
  7. Csaba  Gabor

    Randy Webb Guest

    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/
     
    Randy Webb, Apr 24, 2006
    #7
  8. Csaba  Gabor

    Csaba Gabor Guest

    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
     
    Csaba Gabor, May 2, 2006
    #8
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Roberto Gallo

    Shift - byte[] buf shift

    Roberto Gallo, Jan 27, 2004, in forum: Java
    Replies:
    3
    Views:
    2,194
    Thomas Schodt
    Jan 27, 2004
  2. Wenjie
    Replies:
    3
    Views:
    1,072
    Ron Samuel Klatchko
    Jul 11, 2003
  3. Santosh Nayak

    Left Shift / Right Shift Operators

    Santosh Nayak, Nov 30, 2006, in forum: C Programming
    Replies:
    16
    Views:
    1,495
    CBFalconer
    Nov 30, 2006
  4. Sanny
    Replies:
    38
    Views:
    3,531
    Thomas Richter
    Apr 29, 2011
  5. devphylosoff

    what "shift" does, if not "$_ = shift;" ?

    devphylosoff, Nov 29, 2007, in forum: Perl Misc
    Replies:
    3
    Views:
    371
    Michele Dondi
    Dec 4, 2007
Loading...

Share This Page