Select list without a helper button

V

VK

A while ago there was a discussion how to implement a select list that
would call a function right upon new selection is being made w/o
clicking any additional buttons:

<http://groups-beta.google.com/group...cript+author:VK&rnum=2&hl=en#ba2c264d6a9b3558>

The main issue was to overcome IE's accessibility bug: if user scrolls
the list using arrow keys (or an alternative input device) IE fires
onchange event on each scroll, without <Enter> confirmation. This way a
simple <select onchange="myFunction"> makes your list unaccessible for
non-mouse users. Recently I needed to bypass this issue myself (because
in big interface with many select/button pairs it gets crowdy and
ugly).

IMHO the solution appeared to be too simple to be good. It works on IE
and Opera 8 (except Opera seems doesn't support accesskey (?)
My FF is died today (my fault, not Mozilla). Does it work everywhere
else? That would be really great.

Thanks and thanks in advance to whoever will take a second to check it.



<html>
<head>
<title>Buttonless Select</title>
<meta http-equiv="Content-Type" content="text/html;
charset=iso-8859-1">
<script type="text/javascript">

function keyMode(evt) {
var e = event || evt;
var obj = e.target || e.srcElement;
var key = e.which || e.keyCode;
obj.onchange = foo;
if (key == 13) {processSelected();}
}

function mouseMode(evt) {
var e = event || evt;
var obj = e.target || e.srcElement;
obj.onchange = processSelected;
}

function processSelected() {
alert("Selection detected!");
/* of course something more useful in the reality */
}

function foo() {}

function init() {
var elm = document.forms[0].elements[0];
elm.onkeydown = keyMode;
elm.onmousedown = mouseMode;
}

window.onload = init;
</script>

<style type="text/css">
body { background-color: #FFFFFF}
label { font: 10pt Verdana, Helvetica, sans-serif}
select { font: 10pt Verdana, Helvetica, sans-serif; background-color:
F5F5F5}
..brevier { font: 8pt Verdana, Helvetica, sans-serif}
..u { text-decoration: underline}
</style>

</head>

<body>
<form name="form1">
<label for="dataFile" accesskey="c"><span
class="u">C</span>atalog:</label>
<select id="dataFile">
<option value="0" selected>Please choose one...</option>
<optgroup label="Category One">
<option value="1">Option 1</option>
<option value="2">Option 2</option>
<option value="3">Option 3</option>
</optgroup>
<optgroup label="Category Two">
<option value="4">Option 4</option>
<option value="5">Option 5</option>
<option value="6">Option 6</option>
</optgroup>
<optgroup label="Category Three">
<option value="7">Option 7</option>
<option value="8">Option 8</option>
<option value="9">Option 9</option>
</optgroup>
<optgroup label="Category Four">
<option value="10">Option 10</option>
<option value="11">Option 11</option>
<option value="12">Option 12</option>
</optgroup>
</select>
<noscript>
<font face="Verdana, sans-serif" size="1"
color="red">Disabled</font>
</noscript>
<span class="brevier">Use your mouse or up/down arrow keys
(&lt;Enter&gt; to confirm).</span>
</form>

</body>
</html>
 
M

Michael Winter

A while ago there was a discussion how to implement a select list that
would call a function right upon new selection is being made w/o
clicking any additional buttons: [link snipped]

The main issue was to overcome IE's accessibility bug: if user scrolls
the list using arrow keys (or an alternative input device) IE fires
onchange event on each scroll, without <Enter> confirmation.

I wouldn't call it a bug. The change event is interpreted differently by
different browsers for different controls, and IE is not the only
browser to exhibit this particular behaviour.

The change event is meant to fire after a control has changed in value
since gaining focus /and/ it has subsequently lost focus. Sometimes that
is implemented, but sometimes a click, or some other form of
interaction, will be sufficient.

[snip]
[...] (except Opera seems doesn't support accesskey (?) [...]

It does but you need to switch into access key mode by pressing
Shift+Esc, first.
My FF is died today (my fault, not Mozilla). Does it work everywhere
else? That would be really great.

No. It's 'fine' in Opera 6, but only the keyboard will confirm in all
later versions (including 8). It errors out in Fx and even with
corrections, it fails in NN4. Then there's still the issue of it being
useless with no client-side script support, and it doesn't address the
issues that I've raised previously.

[snip]
function keyMode(evt) {
var e = event || evt;

You've been warned not to refer the global event object directly before,
and here it's come back to bite you.

[snip]
<span class="brevier">Use your mouse or up/down arrow keys
(&lt;Enter&gt; to confirm).</span>

Having to explain how a UI widget works is a sure sign that it's a badly
designed feature.

[snip]

Mike
 
V

VK

[...] (except Opera seems doesn't support accesskey (?) [...]
It does but you need to switch into access key mode by pressing
Shift+Esc, first.

Funny, I had to work yesterday on Windows 98 SE, so I installed Opera 8
there, and accesskey do not work at all (Shift+Esc did not help). But
my code worked (and working) just fine.

Today I reanimated my Windows XP, and accesskey work on the same sample
just fine (on the same Opera 8 build), whether you pressed Shift+Esc or
not. But the code doesn't work as you said. That Opera... That
Windows... That world.

Then there's still the issue of it being
useless with no client-side script support,

Well, for self-updating data-bound page it should not be a
consideration. It's like torturing yourselve with the question: "What
if my visitor will not have a browser?" There is <noscript> tag to
write some consolations and links, I'll do it, and nothing more I can
do.
And Lynx and Gother users are species misterious and usually shagging
on their own selectet places. I don't expect to see any of them around.
and it doesn't address the
issues that I've raised previously.

My issue was just to make the interface as compact as possible and
still Accessibility Act conformant: on the form that will never be
submitted by the definition. But I guess that the choice is either
"onchange" (bye-bye accessibility) or some code like this one (bye-bye
reability). Damn!

You've been warned not to refer the global event object directly before,
and here it's come back to bite you.

Sorry, nightly build!

But you did not say good word about my underlined style instead of
previous <u> tag :-(
I'm a good boy I am! :)
 

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

Forum statistics

Threads
473,770
Messages
2,569,583
Members
45,075
Latest member
MakersCBDBloodSupport

Latest Threads

Top