onclick event not working in IE7

C

Charles

Hello,

On my web site, I have a <select> drop-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 <a> tag, it works fine in IE (but not
within <option> tags). 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.
 
M

Martin Honnen

T

Thomas 'PointedEars' Lahn

Martin said:
Check the IE documentation
<URL:http://msdn2.microsoft.com/en-us/library/ms535877.aspx>, there is
no click or onclick event defined for option elements in IE.

And as a solution to work around this non-standard behavior, the OP should
use the `click' event and `onclick' attribute of the corresponding `select'
element instead.

[1]
http://www.w3.org/TR/REC-html40/interact/forms.html#h-17.6
http://www.w3.org/TR/REC-html40/interact/scripts.html#h-18.2.3
http://www.w3.org/TR/DOM-Level-3-Events/events.html#Events-MouseEvent


PointedEars
 
C

Charles

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

Charles.
 
T

The Natural Philosopher

Charles said:
Hello,

On my web site, I have a <select> drop-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 <a> tag, it works fine in IE (but not
within <option> tags). 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 <select> statement. That works. Its an
IE6/7 feature IIRC.
 
D

David Mark

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

Charles.

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

The Natural Philosopher

David said:
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..;-)
 
L

Lee

The Natural Philosopher said:
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.


--
 
T

The Natural Philosopher

Lee said:
The Natural Philosopher said:

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?
 
D

David Mark

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

Lee

The Natural Philosopher said:
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.


--
 
D

David Cox

The Natural Philosopher said:
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.
 
T

The Natural Philosopher

Lee said:
The Natural Philosopher said:

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

Henri

Hello,

On my web site, I have a <select> drop-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 <a> tag, it works fine in IE (but not
within <option> tags). 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 <select> tag instead; and the event should be
onchange as in onchange="showdiv(this.options[this.selectedIndex].value);"
 
T

The Natural Philosopher

David said:
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'
 
T

The Natural Philosopher

Randy said:
eval("alert(document.getElementById('" + "someID" + "').innerHTML)")

Just because something gives you the results, this time, that you wanted
doesn't make it the best way to do something.

"Best" way is not "right" way.

"best" way depends on a compromise between all factors that in your mind
constitute good quality. That is not a constant.

The "best" way to drive steam valves in the earliest steam engines was
to employ a small boy to turn taps on an off manually as the beam rose
and fell. Till one boy tied some string from the beam to the taps, and
invented automatic valve gear..today it MIGHT be done by a
camshaft..till you get to a racing engine where a bottle of compressed
air does it.

There is no right way. There are ways that work, ways that don't. Of the
ways that work the optimal way depends *ENTIRELY* on the context.

Which is why pedantic arseholes using that term "right' without knowing
the context, betray themselves to be sub optimal programmers of inferior
mental abilities.
 
B

Bart Van der Donck

The said:
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.
 
B

Bart Van der Donck

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

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

The Natural Philosopher

Bart said:
There definitely is.


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

The Natural Philosopher

Bart said:
A <select> with only one <option> can be perfectly valid and
desirable. I can't think of a reason what would be the problem with
that.

Exactly.
The issue then becomes how to trigger a javascript event when someone
selects it.

IE doesn't recognise an 'onchange' event attached to it.
Arguably 'incorrect' on the part of IE, but then IE is full of
'incorrect' code. What are you gong to do about it? Bitch to Bill Gates?

As I discovered, onclick= applied to the <select> statement detects when
it's selected, and you can then inspect the SelectedIndex to find out
what HAS actually been selected. Or which of many similar
<select><Opton> groups.

Ok it doesn't work with a keyboard driven selection.

Nor does any use of 'onclick'

So, simply tell the user to use the mouse in the words above..

As I pointed out, since this function is used by CAD designers, who have
to have a mouse in order to do CAD at all, this is not a serious
downside in this case. ;-)

 

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,982
Messages
2,570,186
Members
46,744
Latest member
CortneyMcK

Latest Threads

Top