onclick event not working in IE7

[Charles]

Hello,

On my web site, I have a <selectdrop-down menu that allows to show/
hide divs: http://tchernobyl.dreamhosters.com - The problem is that it
doesn't work in IE7 (only tested in Opera and Firefox). However, if I
include the onclick event in an <atag, it works fine in IE (but not
within <optiontags). Next to the drop-down menu, I put a "test" link
which works fine in IE7. Do you know what may be the cause? Here's the
snippet:

// Works:

<select>
<option onclick="showdiv('bataille')">La Bataille de Tchernobyl</
option>
<option onclick="showdiv('soleil')">Soleil</option>
<option onclick="showdiv('catastrophe')">La Catastrophe de
Tchernobyl</option>
<option onclick="showdiv('vingt_ans')">Tchernobyl, Vingt Ans
Après</option>
</select>

// Doesn't work:

<a href="#" onclick="showdiv('soleil')">test</a>

Thanks in advance,

Charles.

[Charles]

Thanks guys. I fixed the problem using the <selectelement as
suggested.

Charles.

[The Natural Philosopher]

Charles wrote:

Hello,

On my web site, I have a <selectdrop-down menu that allows to show/
hide divs: http://tchernobyl.dreamhosters.com - The problem is that it
doesn't work in IE7 (only tested in Opera and Firefox). However, if I
include the onclick event in an <atag, it works fine in IE (but not
within <optiontags). Next to the drop-down menu, I put a "test" link
which works fine in IE7. Do you know what may be the cause? Here's the
snippet:

// Works:

<select>
<option onclick="showdiv('bataille')">La Bataille de Tchernobyl</
option>
<option onclick="showdiv('soleil')">Soleil</option>
<option onclick="showdiv('catastrophe')">La Catastrophe de
Tchernobyl</option>
<option onclick="showdiv('vingt_ans')">Tchernobyl, Vingt Ans
Après</option>
</select>

// Doesn't work:

<a href="#" onclick="showdiv('soleil')">test</a>

Thanks in advance,

Charles.

Put the onclick= call in the <selectstatement. That works. Its an
IE6/7 feature IIRC.

[David Mark]

On Oct 7, 12:44 pm, Charles <[e-mail]:

Thanks guys. I fixed the problem using the <selectelement as
suggested.

Charles.

Seems to me that the change event would be more appropriate and
accessible than the click event.

[The Natural Philosopher]

David Mark wrote:

On Oct 7, 12:44 pm, Charles <[e-mail]:

>Thanks guys. I fixed the problem using the <selectelement as
suggested.

Charles.

Seems to me that the change event would be more appropriate and
accessible than the click event.

MM. Until, as I discovered, you end up with only one option, that can't
ever be changed..;-)

[Lee]

The Natural Philosopher said:

>
David Mark wrote:

>On Oct 7, 12:44 pm, Charles <[e-mail]:

>>Thanks guys. I fixed the problem using the <selectelement as
suggested.

Charles.

Seems to me that the change event would be more appropriate and
accessible than the click event.

MM. Until, as I discovered, you end up with only one option, that can't
ever be changed..;-)

In that case, you've coded it wrong.
A selection list should never have only one option, and it's
trivial to ensure that this never happens.
--

[The Natural Philosopher]

Lee wrote:

The Natural Philosopher said:

>David Mark wrote:

>>On Oct 7, 12:44 pm, Charles <[e-mail]:
Thanks guys. I fixed the problem using the <selectelement as
suggested.

Charles.
Seems to me that the change event would be more appropriate and
accessible than the click event.

MM. Until, as I discovered, you end up with only one option, that can't
ever be changed..;-)

In that case, you've coded it wrong.
A selection list should never have only one option, and it's
trivial to ensure that this never happens.

I am not gong to reiterate the reasons why it was intended to be that
way, was not coded wrong, and works perfectly.

The readiness with which people claim righteousness in here and
elsewhere sometimes makes me want to vomit.

There is not sch thing as coded wrong. There is stiff that works as
intended, and stuff that doesn't work as intended. If it works as
intended, how can it be coded wrong?

[David Mark]

On Oct 8, 4:00 pm, The Natural Philosopher <[e-mail]:

Lee wrote:

The Natural Philosopher said:

David Mark wrote:
On Oct 7, 12:44 pm, Charles <[e-mail]:
Thanks guys. I fixed the problem using the <selectelement as
suggested.

>>Charles.
Seems to me that the change event would be more appropriate and
accessible than the click event.

MM. Until, as I discovered, you end up with only one option, that can't
ever be changed..;-)

In that case, you've coded it wrong.
A selection list should never have only one option, and it's
trivial to ensure that this never happens.

I am not gong to reiterate the reasons why it was intended to be that
way, was not coded wrong, and works perfectly.

It was coded wrong as you intended it to "work" incorrectly. Refer
back to the original thread.

[Lee]

The Natural Philosopher said:

>
Lee wrote:

>The Natural Philosopher said:

>>David Mark wrote:
On Oct 7, 12:44 pm, Charles <[e-mail]:
Thanks guys. I fixed the problem using the <selectelement as
suggested.
>
Charles.
Seems to me that the change event would be more appropriate and
accessible than the click event.

MM. Until, as I discovered, you end up with only one option, that can't
ever be changed..;-)

In that case, you've coded it wrong.
A selection list should never have only one option, and it's
trivial to ensure that this never happens.

I am not gong to reiterate the reasons why it was intended to be that
way, was not coded wrong, and works perfectly.

The readiness with which people claim righteousness in here and
elsewhere sometimes makes me want to vomit.

There is not sch thing as coded wrong. There is stiff that works as
intended, and stuff that doesn't work as intended. If it works as
intended, how can it be coded wrong?

Easily. If the way in which it is coded is a perversion of the
way the browser elements were intended to be used, that's a
pretty good sign that it's coded wrong. The fact that it works
the way you intended it to work doesn't make it right. At best
it moves the mistake from your coding to your design.

Making people click on select controls as if they were buttons
is bad user interface design. Period. I don't say that out of
self-righteousness, but based on years of user interface design,
including dealing with user feedback, user support, and updates
to the code.

Particular in browser environments, trying to make controls behave
other than as they were designed to is almost always a mistake.
It's too likely that the next browser release or some browser that
a client insists on using won't support whatever hacks you have to
use to get the behavior you want.

Even if you think you know your user base, you have to consider
that user bases change. The company that uses strictly IE may
hire somebody who requires a special browser to accommodate some
disability or the CIO may play a round of golf with somebody who
argues convincingly for Opera.
--

[David Cox]

"The Natural Philosopher" <[e-mail] in message
news:11****************@proxy00.news.clara.net...

Lee wrote:

>The Natural Philosopher said:

>>David Mark wrote:
On Oct 7, 12:44 pm, Charles <[e-mail]:
Thanks guys. I fixed the problem using the <selectelement as
suggested.
>
Charles.
Seems to me that the change event would be more appropriate and
accessible than the click event.

MM. Until, as I discovered, you end up with only one option, that can't
ever be changed..;-)

In that case, you've coded it wrong.
A selection list should never have only one option, and it's
trivial to ensure that this never happens.

I am not gong to reiterate the reasons why it was intended to be that way,
was not coded wrong, and works perfectly.

The readiness with which people claim righteousness in here and elsewhere
sometimes makes me want to vomit.

There is not sch thing as coded wrong. There is stiff that works as
intended, and stuff that doesn't work as intended. If it works as
intended, how can it be coded wrong?

One of the hard lessons is that just because it works, it does not mean it
is right.

The harder lesson is that "not right" can have a fearsome bite.

If you have not learned that, I hope your luck holds.

[The Natural Philosopher]

Lee wrote:

The Natural Philosopher said:

>Lee wrote:

>>The Natural Philosopher said:
David Mark wrote:
On Oct 7, 12:44 pm, Charles <[e-mail]:
>Thanks guys. I fixed the problem using the <selectelement as
>suggested.
>>
>Charles.
Seems to me that the change event would be more appropriate and
accessible than the click event.
>
MM. Until, as I discovered, you end up with only one option, that can't
ever be changed..;-)
In that case, you've coded it wrong.
A selection list should never have only one option, and it's
trivial to ensure that this never happens.

I am not gong to reiterate the reasons why it was intended to be that
way, was not coded wrong, and works perfectly.

The readiness with which people claim righteousness in here and
elsewhere sometimes makes me want to vomit.

There is not sch thing as coded wrong. There is stiff that works as
intended, and stuff that doesn't work as intended. If it works as
intended, how can it be coded wrong?

Easily. If the way in which it is coded is a perversion of the
way the browser elements were intended to be used, that's a
pretty good sign that it's coded wrong.

God, another religious pervert.

And hpow paty, wre borswer intended to be used?

If you look at what they are used for these days, and compare with the
original intention - the sharing of reasearch papers across the net,
then javascript itself is 'wrong'

The fact that it works
the way you intended it to work doesn't make it right. At best
it moves the mistake from your coding to your design.

Oh my gawd.

I bet all our barbecues are very expensive, and run of bottled gas, and
you have never punched holes in an oil drum and fill it full of wood to
cook our steaks. "Wrong use of an oildrum".

Thank heavens yy weren;t there when someone forst used a log to roll a
stone down a slope 'wrong use of a log'
I can tell you are PROBABLY some snotty computer scuentist escaped from
college.

I am an engineer: there is no right or wrong, there is what works, and
what doesn't. All engineering is the exploitation of unexpected
properties of the material world to achieve a specific aim.

If I want to put a single line of clickable text in a box that looks
like the multiple lines of clickable text in he other select boxes, that
is not WRONG.

Using javascript with form input elements in *every* case is NOT what
the designers of form elements ever intended. Strictly one ought to
throw away the form elements and do the thing in pure javascript, but
that is non standard across browsers in so many ways..

Making people click on select controls as if they were buttons

That is not what this code does. It splits options from a very long list
into sub lists, simply t make it easier to find the right option without
yards of scrolling.

On occasion, some of those sub lists contain just one element.

is bad user interface design. Period. I don't say that out of
self-righteousness, but based on years of user interface design,
including dealing with user feedback, user support, and updates
to the code.

Yawn. YOU write some code that allows selection of *one* item and one
alone from several drop down lists one or more of which may contain only
one element.

I found a way that has a consistent look and feel and works in all
browsers.

As an engineer, that is all I ask.

Particular in browser environments, trying to make controls behave
other than as they were designed to is almost always a mistake.
It's too likely that the next browser release or some browser that
a client insists on using won't support whatever hacks you have to
use to get the behavior you want.

That goes for almost everything one ever writes.

Even if you think you know your user base, you have to consider
that user bases change. The company that uses strictly IE may
hire somebody who requires a special browser to accommodate some
disability or the CIO may play a round of golf with somebody who
argues convincingly for Opera.

MM. Unlikely in all cases. Since the use to which this particular form
is put involves the ability to draw CAD files. And deaf dumb and blind
idiots may be be able to play pinball, but they are remarkably rare in
CAD drafting.

Asfar as te CEO goes, well Mike doesn't play golf, and the machines that
drive his laser cutters have to be PC's and come with IE7 so thats
really it. As ar as external designers inputting data via this form
goes, it works on all browsers to date.

Feel free to write me the 'proper' version..right now I have about
another 20 screens of code to write and no time frankly.

>

[Henri]

On Sun, 07 Oct 2007 14:31:14 +0000, Charles wrote:

Hello,

On my web site, I have a <selectdrop-down menu that allows to show/
hide divs: http://tchernobyl.dreamhosters.com - The problem is that it
doesn't work in IE7 (only tested in Opera and Firefox). However, if I
include the onclick event in an <atag, it works fine in IE (but not
within <optiontags). Next to the drop-down menu, I put a "test" link
which works fine in IE7. Do you know what may be the cause? Here's the
snippet:

// Works:

<select>
<option onclick="showdiv('bataille')">La Bataille de Tchernobyl</
option>
<option onclick="showdiv('soleil')">Soleil</option<option
onclick="showdiv('catastrophe')">La Catastrophe de
Tchernobyl</option>
<option onclick="showdiv('vingt_ans')">Tchernobyl, Vingt Ans
Après</option>
</select>

// Doesn't work:

<a href="#" onclick="showdiv('soleil')">test</a>

Thanks in advance,

Charles.

it won't work that way: you cannot associate any event to the <option>
tag. Attach it to the <selecttag instead; and the event should be
onchange as in onchange="showdiv(this.options[this.selectedIndex].value);"

[The Natural Philosopher]

David Cox wrote:

"The Natural Philosopher" <[e-mail] in message
news:11****************@proxy00.news.clara.net...

>Lee wrote:

>>The Natural Philosopher said:
David Mark wrote:
On Oct 7, 12:44 pm, Charles <[e-mail]:
>Thanks guys. I fixed the problem using the <selectelement as
>suggested.
>>
>Charles.
Seems to me that the change event would be more appropriate and
accessible than the click event.
>
MM. Until, as I discovered, you end up with only one option, that can't
ever be changed..;-)
In that case, you've coded it wrong.
A selection list should never have only one option, and it's
trivial to ensure that this never happens.

I am not gong to reiterate the reasons why it was intended to be that way,
was not coded wrong, and works perfectly.

The readiness with which people claim righteousness in here and elsewhere
sometimes makes me want to vomit.

There is not sch thing as coded wrong. There is stiff that works as
intended, and stuff that doesn't work as intended. If it works as
intended, how can it be coded wrong?

One of the hard lessons is that just because it works, it does not mean it
is right.

I learnt that many any moons ago.
When my first transistor radio stopped working in the sun...

The harder lesson is that "not right" can have a fearsome bite.

Oh nded.

Fortunately software is far more predictable than hardware.

You can vary the data input, and the browser, but that's it.

In this case teh oly variable is the browser. It works on all of them.

Select/options can and do work perfectly on a single element. Its
javascript that gets a shade confused.

Probably because its writen by nerds who have cler ideas about whats
'rght' and 'wrong' and so decided that clicking and sleectng a single
element did not represent a 'change' and therefore 'onchange' should not
be calld..except if the element was NOT selected, clicking on it toggles
it to selected., which IS a change.

my code is merely a workaround for an IE 'bug'

If you have not learned that, I hope your luck holds.

[Bart Van der Donck]

The Natural Philosopher wrote:

There is not sch thing as coded wrong.

There definitely is.

There is stiff that works as intended, and stuff that doesn't
work as intended. If it works as intended, how can it be coded
wrong?

If you connect a gas stove in your kitchen and "it works as intended",
is that enough for you? You will want to perform a pressure test, use
the right tube fittings, get certificate, etc.

--
Bart

[Bart Van der Donck]

Lee wrote:

A selection list should never have only one option, and it's
trivial to ensure that this never happens.

A <selectwith only one <optioncan be perfectly valid and
desirable. I can't think of a reason what would be the problem with
that.

--
Bart

[The Natural Philosopher]

Bart Van der Donck wrote:

The Natural Philosopher wrote:

>There is not sch thing as coded wrong.

There definitely is.

>There is stiff that works as intended, and stuff that doesn't
work as intended. If it works as intended, how can it be coded
wrong?

If you connect a gas stove in your kitchen and "it works as intended",
is that enough for you? You will want to perform a pressure test, use
the right tube fittings, get certificate, etc.

Of course. That's part of making sure it works 'as intended'.

Likewise you test against all browsers in all categories that the code
is intended to be used in.

One does not test against a text only browser for example, any more than
you routinely test a gas cooker for use on pure hydrogen.

Being an engineer, teaches you that life is not perfect,and neither is
any solution except in the narrowest of examples: engineering is about
cost effective solutions that are good enough. Fit for purpose.

Take the current trend to replace cam timing chains or gears, by belts,
in production cars.

Is this a correct solution? They break after 50,000-100,000 miles and
often destroy part of the engine when they do.

So why not use gears or chains?

Simple. They are expensive, noisy and need lubrication, so require
extensive dismantling to replace..and in the case of chains suffer
equally from stretch and time changing over time, though they seldom BREAK.

Belts are cheap, quiet, easy to replace, and do the job WELL ENOUGH.

I could cite a million more examples. Up to an including the engineering
decisions that caused two space shuttles to crash. In the end they
weren't quite good *enough*...

Sorry. There is no "correct" solution to any software problem, except in
pure syntax terms. Ther are ones that work, ones that don't work at all
and ones that work some of the time. Testing and "good" (not "correct")
design should eleminate the last two categories.

As it does with gas cooker installation.

Or space shuttles. Well sometimes anyway ;-)

>
--
Bart

[David Mark]

On Oct 9, 6:13 am, Bart Van der Donck <[e-mail]:

Lee wrote:

A selection list should never have only one option, and it's
trivial to ensure that this never happens.

A <selectwith only one <optioncan be perfectly valid and
desirable. I can't think of a reason what would be the problem with

Valid, but hardly desirable from an interface standpoint. Regardless,
the other thread that triggered this one-option-per-select argument
related a single-option select that had to be clicked to fill in a
hidden input. Clearly the single-option select should have been a
hidden input in the first place. Requiring the user to click a select
with one option as a "workaround" for a poor interface design is not
acceptable.

[Bart Van der Donck]

David Mark wrote:

On Oct 9, 6:13 am, Bart Van der Donck <[e-mail]:

>A <selectwith only one <optioncan be perfectly valid and
desirable. I can't think of a reason what would be the problem with

Valid, but hardly desirable from an interface standpoint. Regardless,
the other thread that triggered this one-option-per-select argument
related a single-option select that had to be clicked to fill in a
hidden input. Clearly the single-option select should have been a
hidden input in the first place. Requiring the user to click a select
with one option as a "workaround" for a poor interface design is not
acceptable.

Generally spoken, I think one-option-selects are acceptable in select-
lists that depend on some kind of previous filter (set by the user, by
the available data, ...). If there is no such filter, the nature of
this elements make it a bit odd to use only one option.

--
Bart

[Lee]

The Natural Philosopher said:

>
Lee wrote:

>The Natural Philosopher said:

>>Lee wrote:
The Natural Philosopher said:
David Mark wrote:
>On Oct 7, 12:44 pm, Charles <[e-mail]:
>>Thanks guys. I fixed the problem using the <selectelement as
>>suggested.
>>>
>>Charles.
>Seems to me that the change event would be more appropriate and
>accessible than the click event.
>>
MM. Until, as I discovered, you end up with only one option, that can't
ever be changed..;-)
In that case, you've coded it wrong.
A selection list should never have only one option, and it's
trivial to ensure that this never happens.
I am not gong to reiterate the reasons why it was intended to be that
way, was not coded wrong, and works perfectly.

The readiness with which people claim righteousness in here and
elsewhere sometimes makes me want to vomit.

There is not sch thing as coded wrong. There is stiff that works as
intended, and stuff that doesn't work as intended. If it works as
intended, how can it be coded wrong?

Easily. If the way in which it is coded is a perversion of the
way the browser elements were intended to be used, that's a
pretty good sign that it's coded wrong.

God, another religious pervert.

And hpow paty, wre borswer intended to be used?

If you look at what they are used for these days, and compare with the
original intention - the sharing of reasearch papers across the net,
then javascript itself is 'wrong'

Do you not understand the difference between a browser and
a browser element?

> The fact that it works
the way you intended it to work doesn't make it right. At best
it moves the mistake from your coding to your design.

Oh my gawd.

I bet all our barbecues are very expensive, and run of bottled gas, and
you have never punched holes in an oil drum and fill it full of wood to
cook our steaks. "Wrong use of an oildrum".

Thank heavens yy weren;t there when someone forst used a log to roll a
stone down a slope 'wrong use of a log'

Your analogies are badly flawed, suggesting that you've missed
the point.

If, for example, you punched holes in an oil drum and filled it
full of wood and set it a storage room full of drums filled with
oil, that would be "wrong use of an oil drum", because it would
cause confusion to the users and create a headache for whoever
is responsible for maintaining that storage room.

>I can tell you are PROBABLY some snotty computer scuentist escaped from
college.

I've been a software engineer working in the real world for (I
would assume) most of your lifetime.

>I am an engineer: there is no right or wrong, there is what works, and
what doesn't. All engineering is the exploitation of unexpected
properties of the material world to achieve a specific aim.

Engineering also involves considering more than functionality.
You must consider usability, stability, maintainability,
portability, and a host of other "-ilities" that go far beyond
function. If you don't consider them, you're not an engineer.

>If I want to put a single line of clickable text in a box that looks
like the multiple lines of clickable text in he other select boxes, that
is not WRONG.

If you implement it as a single option select control and have to
write hack code to make it work as you intend, and have to explain
to the users that this select control, unlike any other they've
used, actually functions like a pushbutton, then yes, it's wrong.

>Using javascript with form input elements in *every* case is NOT what
the designers of form elements ever intended. Strictly one ought to
throw away the form elements and do the thing in pure javascript, but
that is non standard across browsers in so many ways..

Modern browsers were written with the intention of allowing
interaction with Javascript. They weren't written with the
intention that self-styled engineers would pervert the basic
usage models.

>Making people click on select controls as if they were buttons

That is not what this code does. It splits options from a very long list
into sub lists, simply t make it easier to find the right option without
yards of scrolling.

On occasion, some of those sub lists contain just one element.

Then that is, indeed, "what this code does".

>is bad user interface design. Period. I don't say that out of
self-righteousness, but based on years of user interface design,
including dealing with user feedback, user support, and updates
to the code.

Yawn. YOU write some code that allows selection of *one* item and one
alone from several drop down lists one or more of which may contain only
one element.

Have you considered that drop down lists may not be the best
user interface for this task?

>I found a way that has a consistent look and feel and works in all
browsers.

As an engineer, that is all I ask.

Then you're not an engineer.

>Particular in browser environments, trying to make controls behave
other than as they were designed to is almost always a mistake.
It's too likely that the next browser release or some browser that
a client insists on using won't support whatever hacks you have to
use to get the behavior you want.

That goes for almost everything one ever writes.

Are you saying that it isn't obvious to you that writing code to
make controls work in ways that they weren't intended to work is
inherently more likely to a maintenance issue?

>Even if you think you know your user base, you have to consider
that user bases change. The company that uses strictly IE may
hire somebody who requires a special browser to accommodate some
disability or the CIO may play a round of golf with somebody who
argues convincingly for Opera.

MM. Unlikely in all cases. Since the use to which this particular form
is put involves the ability to draw CAD files. And deaf dumb and blind
idiots may be be able to play pinball, but they are remarkably rare in
CAD drafting.

You don't have to be deaf, dumb or blind to require accommodations.
I've known people to use CAD tools on special monitors and with
special input devices as accommodations.

>Feel free to write me the 'proper' version..right now I have about
another 20 screens of code to write and no time frankly.

Don't worry. You, or your successor, will wind up writing it
correctly sooner or later.
--

[Lee]

Bart Van der Donck said:

>
Lee wrote:

>A selection list should never have only one option, and it's
trivial to ensure that this never happens.

A <selectwith only one <optioncan be perfectly valid and
desirable. I can't think of a reason what would be the problem with
that.

A select list with one element might be considered valid
(but I won't concede "desirable") in the case where it
functions to show that there is only one choice available
which will be submitted when the user submits the form.

It's certainly not valid when the user interface requires
the user to click on that single option, as in the case
that is being defended.
--

[The Natural Philosopher]

Lee wrote:

The Natural Philosopher said:

>Lee wrote:

>

>I can tell you are PROBABLY some snotty computer scuentist escaped from
college.

I've been a software engineer working in the real world for (I
would assume) most of your lifetime.

Mm. Lets see. Half of my life takes us to 1978. I guess MOST of my life
would take us back to 1970...I guess its JUST possible that you have
been programming computers since then , but I doubt it.