onchange event in select element with keyboard scrolling in IE6

A

andypb123

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
 
T

Thomas 'PointedEars' Lahn

andypb123 said:
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
 
E

Eric B. Bednarz

Thomas 'PointedEars' Lahn said:
andypb123 said:
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.
 
E

Eric B. Bednarz

Eric B. Bednarz said:
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).
 
T

Thomas 'PointedEars' Lahn

Eric said:
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] <
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 |
“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
 
A

andypb123

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

Thomas 'PointedEars' Lahn

andypb123 said:
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
 
A

andypb123

You are welcome.


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
 
T

Thomas 'PointedEars' Lahn

andypb123 said:
Thomas said:
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
 
A

andypb123

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
 
T

Thomas 'PointedEars' Lahn

andypb123 said:
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 <already.


PointedEars
 
T

Thomas 'PointedEars' Lahn

andypb123 said:
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
 
D

David Mark


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?
 

Ask a Question

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

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

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top