onchange event in select element with keyboard scrolling in IE6

Discussion in 'Javascript' started by andypb123, Oct 15, 2008.

  1. andypb123

    andypb123 Guest

    Hello,
    The onchange event fires in IE6 in a SELECT element when scrolling
    through the list with the up and down arrows on the keyboard. In
    Firefox it only fires after you hit the enter key, which is the
    behaviour I want make happen in IE.
    Does anyone know how to accomplish this?
    Thanks a lot
    Andy Birchall
    andypb123, Oct 15, 2008
    #1
    1. Advertising

  2. andypb123 wrote:
    > The onchange event fires in IE6 in a SELECT element when scrolling
    > through the list with the up and down arrows on the keyboard. In
    > Firefox it only fires after you hit the enter key, which is the
    > behaviour I want make happen in IE.
    > Does anyone know how to accomplish this?


    Keypresses trigger keyboard events. But provided your `select' element has
    size > 1, you are mistaken: the `change' event is triggered by changing the
    selection of such a control with keyboard or pointing device (as established
    here recently).


    PointedEars
    --
    Prototype.js was written by people who don't know javascript for people
    who don't know javascript. People who don't know javascript are not
    the best source of advice on designing systems that use javascript.
    -- Richard Cornford, cljs, <f806at$ail$1$>
    Thomas 'PointedEars' Lahn, Oct 15, 2008
    #2
    1. Advertising

  3. Thomas 'PointedEars' Lahn <> writes:

    > andypb123 wrote:
    >> The onchange event fires in IE6 in a SELECT element when scrolling
    >> through the list with the up and down arrows on the keyboard. In
    >> Firefox it only fires after you hit the enter key, […]


    Don’t rely on any behaviour like that. It could even be different with
    the same browser on different operating systems.

    > Keypresses trigger keyboard events. But provided your `select' element has
    > size > 1,


    Could you explain what the value of the select element’s size attribute
    has to do with this? :)

    > you are mistaken: the `change' event is triggered by changing the
    > selection of such a control with keyboard or pointing device (as established
    > here recently).


    “Utter nonsenseâ€

    In Firefox and Google Chrome you can tab into the select control
    (i.e. give it focus) and scroll through the available options with the
    up/down arrow keys *without* the change event firing. It fires
    * when you hit enter/return key or
    * on blur

    In Internet Explorer and Opera that’s impossible (you would need to
    click on the select box first to show all options and then use the
    up/down keys to select an option and then hit enter/return to change
    it).

    Safari (OS X) always shows all available options on focus, so it doesn’t
    fire the change event either when you use the up/down arrows, but here
    the user interface makes it obvious that an additional action is
    required. IMNSHO this is the best user interface because it does away
    with the differences between keyboard and pointing device as mentioned
    above.


    --
    ||| hexadecimal EBB
    o-o decimal 3771
    --oOo--( )--oOo-- octal 7273
    205 goodbye binary 111010111011
    Eric B. Bednarz, Oct 16, 2008
    #3
  4. Eric B. Bednarz <> writes:

    > Safari (OS X) always shows all available options on focus, […]


    That was a mistake, it does so when using the up/down key after
    focus. After that up/down highlights the previous/next option (without
    selecting it).

    On windows it doesn’t, but behaves like Firefox and Chrome (the latter
    is rather unsurprising of course).
    Eric B. Bednarz, Oct 16, 2008
    #4
  5. Eric B. Bednarz wrote:
    > Thomas 'PointedEars' Lahn <> writes:
    >> andypb123 wrote:
    >> Keypresses trigger keyboard events. But provided your `select' element has
    >> size > 1,

    >
    > Could you explain what the value of the select element’s size attribute
    > has to do with this? :)


    As you could have noticed[1], if size > 1 (i.e. list, not dropdown list) the
    `change' event is triggered at least in newer Geckos by change of selection
    alone; the control does not need to lose focus first.

    [1] <news:>

    What is most interesting, though, is that with size=1 in that UA the
    `change' event also occurs already when the selection changed, provided the
    dropdown list was expanded; the control does not need to lose focus first
    then. In fact, when it loses focus in that case, no additional `change'
    event is created (contrary to the W3C DOM Level 2 Specification). However,
    the situation is different if the dropdown list is not extended; then there
    is no `change' event when the selection changes, but only when the selection
    changed and the control loses focus (as specified).

    So, summarized, these are my observations for Mozilla/5.0 (Windows; U;
    Windows NT 5.1; en-GB; rv:1.9.0.3) Gecko/2008092417 Firefox/3.0.3, using
    Firebug 1.2.1 for logging events:

    | selection changes | loss of focus (tab away)
    | (Dn +opt. <RET>) |
    ----------------------+---------------------------|--------------------------
    size = 1 not expanded | keydown, keypress, keyup | keydown, keypress,
    | | change, blur
    | |
    size = 1 expanded | keydown, keypress, keyup; | keydown, keypress, blur
    | keydown, keypress, |
    | popuphiding, change |
    | |
    size > 1 | keydown, keypress, change,| keydown, keypress, blur
    | keyup |

    >> you are mistaken: the `change' event is triggered by changing the
    >> selection of such a control with keyboard or pointing device (as established
    >> here recently).

    >
    > “Utter nonsenseâ€


    Is that so? Which Firefox version on which OS have you tested with? Which
    rendering mode was used?

    > In Firefox and Google Chrome you can tab into the select control
    > (i.e. give it focus) and scroll through the available options with the
    > up/down arrow keys *without* the change event firing. It fires
    > * when you hit enter/return key or
    > * on blur


    Apparently that is different if size > 1.


    PointedEars
    --
    Prototype.js was written by people who don't know javascript for people
    who don't know javascript. People who don't know javascript are not
    the best source of advice on designing systems that use javascript.
    -- Richard Cornford, cljs, <f806at$ail$1$>
    Thomas 'PointedEars' Lahn, Oct 16, 2008
    #5
  6. andypb123

    andypb123 Guest

    Hi, thanks a lot for your responses.
    However am I right in thinking from your posts that there is no
    solution to get this working in IE6 on Windows machines?
    i.e. enabling the user scroll through the list, when it is unexpanded,
    with the keyboard up and down arrows.

    Below is simple HTML code which demostrates the problem. In IE6 the
    alert box fires up when the user scrolls through the select list with
    the up and down arrows. In Firefox (and other browsers mentioned
    above) it doesn't fire until you hit the enter key.
    Thanks
    Andy Birchall

    <html>
    <head>
    <script type="text/javascript">
    function alertMsg(id) {
    alert(document.getElementById(id).value);
    }
    </script>
    </head>
    <body>
    Choose your animal:
    <select id="pets" name="animals" onchange="alertMsg(this.id)">
    <option value="Please">Please select an animal</option>
    <option value="cat">Cat</option>
    <option value="dog">Dog</option>
    <option value="budgie">Budgie</option>
    <option value="turtle">Turtle</option>
    </select>
    </body>
    </html>
    andypb123, Oct 17, 2008
    #6
  7. andypb123 wrote:
    > Hi, thanks a lot for your responses.


    You are welcome.

    > However am I right in thinking from your posts that there is no
    > solution to get this working in IE6 on Windows machines?


    As I have said, you can listen to keyboard events instead. RTFM.


    PointedEars
    --
    Use any version of Microsoft Frontpage to create your site.
    (This won't prevent people from viewing your source, but no one
    will want to steal it.)
    -- from <http://www.vortex-webdesign.com/help/hidesource.htm>
    Thomas 'PointedEars' Lahn, Oct 17, 2008
    #7
  8. andypb123

    andypb123 Guest

    On 17 Oct, 22:39, Thomas 'PointedEars' Lahn <>
    wrote:
    > andypb123 wrote:
    > > Hi, thanks a lot for your responses.

    >
    > You are welcome.
    >
    > > However am I right in thinking from your posts that there is no
    > > solution to get this working in IE6 on Windows machines?

    >
    > As I have said, you can listen to keyboard events instead.  RTFM.
    >
    > PointedEars
    > --
    > Use any version of Microsoft Frontpage to create your site.
    > (This won't prevent people from viewing your source, but no one
    > will want to steal it.)
    >   -- from <http://www.vortex-webdesign.com/help/hidesource.htm>


    That doesn't help beacuse I want the user to be able to scroll trough
    the list with the mouse AND the keyboard and to be able to select an
    option with either. With Firefox it works fine with the keyboard or
    the mouse by just catching the "onchange" event but unfortunatley I
    have to support IE6 as well with this particular app. I have tried
    several variations on catching "keyup", "keydown" and "onchange"
    events but haven't been able to get anything to work.
    Thanks
    andypb123, Oct 22, 2008
    #8
  9. andypb123

    rf Guest

    "andypb123" <> wrote in message
    news:...
    On 17 Oct, 22:39, Thomas 'PointedEars' Lahn <>

    ....

    >> PointedEars
    >> --
    >> Use any version of Microsoft Frontpage to create your site.
    >>(This won't prevent people from viewing your source, but no one
    >> will want to steal it.)
    >> -- from <http://www.vortex-webdesign.com/help/hidesource.htm>


    >That doesn't help


    FFS what doesn't help? Using "any version of Microsoft Frontpage" doesn't
    help?

    Learn to trim correctly please.
    rf, Oct 22, 2008
    #9
  10. andypb123 wrote:
    > Thomas 'PointedEars' Lahn wrote:
    >> andypb123 wrote: [...]
    >>> However am I right in thinking from your posts that there is no
    >>> solution to get this working in IE6 on Windows machines?

    >> As I have said, you can listen to keyboard events instead. RTFM.
    >>
    >> [signatures]


    Please learn to quote. How to post properly is described, last but not
    least, in the FAQ of this newsgroup: <http://jibbering.com/faq/>. Pointers
    to the FAQ are posted this often here (both by regulars and automatically)
    that they can hardly go unnoticed.

    > That doesn't help beacuse I want the user to be able to scroll trough the
    > list with the mouse AND the keyboard and to be able to select an option
    > with either.


    So what? Listening to keyboard events instead of `onchange' does not
    prevent users from using the mouse. And there are also mouse events.
    RTFM, finally.

    > With Firefox it works fine with the keyboard or the mouse by just
    > catching the "onchange" event but unfortunatley I have to support IE6 as
    > well with this particular app.


    That doesn't matter.

    > I have tried several variations on catching "keyup", "keydown" and
    > "onchange" events but haven't been able to get anything to work.


    That is an utterly useless statement.


    PointedEars
    --
    realism: HTML 4.01 Strict
    evangelism: XHTML 1.0 Strict
    madness: XHTML 1.1 as application/xhtml+xml
    -- Bjoern Hoehrmann
    Thomas 'PointedEars' Lahn, Oct 22, 2008
    #10
  11. andypb123

    andypb123 Guest

    FYI there is an easy 'fix' for this, which I'm posting for the benifit
    of the newsgroup. When the focus is on the select list, hit the Alt
    key + the up or down arrow key, which expands the list, which you can
    then scroll through using the up/down arrow keys.
    AB
    andypb123, Oct 29, 2008
    #11
  12. andypb123 wrote:
    > FYI there is an easy 'fix' for this, which I'm posting for the benifit
    > of the newsgroup. When the focus is on the select list, hit the Alt
    > key + the up or down arrow key, which expands the list, which you can
    > then scroll through using the up/down arrow keys.


    Yes, I said that in <news:> already.


    PointedEars
    --
    Prototype.js was written by people who don't know javascript for people
    who don't know javascript. People who don't know javascript are not
    the best source of advice on designing systems that use javascript.
    -- Richard Cornford, cljs, <f806at$ail$1$>
    Thomas 'PointedEars' Lahn, Oct 29, 2008
    #12
  13. andypb123

    andypb123 Guest

    On 29 Oct, 18:13, Thomas 'PointedEars' Lahn <>
    wrote:
    > andypb123 wrote:
    > > FYI there is an easy 'fix' for this, which I'm posting for the benifit
    > > of the newsgroup. When the focus is on the select list, hit the Alt
    > > key + the up or down arrow key, which expands the list, which you can
    > > then scroll through using the up/down arrow keys.

    >
    > Yes, I said that in <news:> already.
    >


    No you didn't.
    andypb123, Nov 4, 2008
    #13
  14. andypb123 wrote:
    > Thomas 'PointedEars' Lahn wrote:
    >> andypb123 wrote:
    >>> FYI there is an easy 'fix' for this, which I'm posting for the benifit
    >>> of the newsgroup. When the focus is on the select list, hit the Alt
    >>> key + the up or down arrow key, which expands the list, which you can
    >>> then scroll through using the up/down arrow keys.

    >> Yes, I said that in <news:> already.

    >
    > No you didn't.


    I talked about differences in events between expanded and not expanded
    `select' elements of size=1 there. Alt+(Arrow (Up|Down)) is one way to
    expand those controls in some user agents, and in particular in the ones
    in question here.


    PointedEars
    --
    realism: HTML 4.01 Strict
    evangelism: XHTML 1.0 Strict
    madness: XHTML 1.1 as application/xhtml+xml
    -- Bjoern Hoehrmann
    Thomas 'PointedEars' Lahn, Nov 4, 2008
    #14
  15. andypb123

    David Mark Guest

    On Mar 18, 2:16 am, f </> wrote:
    > f


    My thoughts exactly. :)

    The change event is virtually worthless for SELECT elements due to
    creative interpretations of the relevant specs. This has been the
    case for as long as I can remember. Similarly, it is a bad idea for
    checkboxes and radio buttons.

    What to do? As always, it depends on what you are after. There's no
    singular (standard or not) behavior that makes the change event ideal
    for every occasion. Sometimes you don't care if the value has changed
    until blur (e.g. validation). In that case, use blur and compare the
    current value to the previous. Sometimes you want to synchronize the
    state of adjacent controls, requiring that notifications come prior to
    blur. As Thomas mentioned, the keyboard events keep you informed to
    *potential* changes in progress (which may not turn out to be changes
    at all). And it doesn't hurt to treat potential changes as real ones
    (though it's obviously not efficient). You might throw mouseup in
    there too for completeness.

    It's another one of those things that is easily avoidable. You just
    have to know about it in advance. Or... You could use some time-
    waster's attempt to "normalize" change events for "all browsers" (in
    whatever way they feel is the singular best practice). Are there
    really any takers for something like that?
    David Mark, Mar 21, 2011
    #15
    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. Covad
    Replies:
    1
    Views:
    184
    Richard Cornford
    Nov 3, 2003
  2. Ryan McGeary
    Replies:
    2
    Views:
    185
    Thomas 'PointedEars' Lahn
    Jan 7, 2004
  3. Robert Carlson
    Replies:
    2
    Views:
    122
    Richard Cornford
    Sep 14, 2004
  4. Bart van Deenen
    Replies:
    3
    Views:
    124
    Bart van Deenen
    Feb 17, 2005
  5. Replies:
    2
    Views:
    172
Loading...

Share This Page