JavaScript Document Code Not Cross Platform

B

bradwiseathome

I have code that works in IE 6 but does not work in FireFox 1.0.2, how
can I change it so it works in both browsers?


<html>
<head>
<script language="JavaScript" type="text/JavaScript">
function AttributeSelected()
{
var selectVal = document.forms['testspit'].elements['lsbRA'].options;
if (selectVal.value == 'Item1')
{
document.getElementById('text2').style.visibility='visible';
document.getElementById('spnlabel').style.visibility='visible';
}
else
{
document.getElementById('text2').style.visibility='hidden';
document.getElementById('spnlabel').style.visibility='hidden';
}
}
</script>
</head>
<body>
<form name="testspit" method="post" action="">
<div id="divPlace" style="width:90%;left:10px;top:40px">
<select multiple id="lsbRA" onChange="AttributeSelected();" >
<option value="Item1">Item 1</option>
<option value="Item2">Item 2 </option>
</select>
<br/><br/>
<input name="text1" type="text" value="text1" size="20">
<br/><br/>
<span id="spnlabel" style="overflow:hidden">
-
</span>
<span id="spntext" style="overflow:hidden">
<input name="text2" type="text" value="text2" size="20">
</span>
</div>
</body>
</html>


Thanks.
 
R

RobG

I have code that works in IE 6 but does not work in FireFox 1.0.2, how
can I change it so it works in both browsers?

Missing DOCTYPE - that has ramifications here (see below), suggest:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">

<html>
<head>
<script language="JavaScript" type="text/JavaScript">

The language attribute is depreciated, keep the required type
attribute.
function AttributeSelected()
{
var selectVal =
document.forms['testspit'].elements['lsbRA'].options;

In quirksmode (sans DOCTYPE) IE handles this, Firefox doesn't. If
lsbRA was a single select, then using the above suggested DOCTYPE with:

var selectVal = document.forms['testspit'].elements['lsbRA'];

will fix the issue if 'lsbRA' is a single select - take care, if the
option has no 'value' attribute the value is supposed to be the text,
but IE doesn't understand that.

Adding '.options' on the end returns a collection of the options, which
has no 'value' attribute (it is effectively an array). Removing
'.options' means selectVal will be the element 'lsbRA', whose value
will be that of the selected option.

Since 'lsbRA' is a multiselect, you need to iterate through the options
to find which ones are selected, you can't just get the value. Wrap
your function with a loop that goes through all the options and deals
with the selected ones, so now you have:

var selectVal = document.forms['testspit'].elements['lsbRA'];
for (var i=0, j=selectVal.length; i<j; i++){
if (selectVal.selected){
alert(selectVal.value + ' selected'); // Purely de-bug...
...

if (selectVal.value == 'Item1')

becomes:

if (selectVal.value == 'Item1')

{
document.getElementById('text2').style.visibility='visible';

Here you are using getElementById on elements that have no ID. IE
treats names and IDs as virtually the same thing, Firefox doesn't
(because they are very different things but overlap somewhat in
purpose). ID and NAME share the same namespace, so if you can't have
different elements with the same name & id. You can, in some
circumstances, have the same name on multiple elements.

The quick 'n dirty solution here is to put the same ID on your elements
as the name you've already given them.
document.getElementById('spnlabel').style.visibility='visible';
}
else
{
document.getElementById('text2').style.visibility='hidden';
document.getElementById('spnlabel').style.visibility='hidden';
}

Add a couple of curly braces to close the added for and if loops.

}
}
}
</script>
</head>
<body>
<form name="testspit" method="post" action="">
<div id="divPlace" style="width:90%;left:10px;top:40px">
<select multiple id="lsbRA" onChange="AttributeSelected();" >
<option value="Item1">Item 1</option>
<option value="Item2">Item 2 </option>
</select>
<br/><br/>
<input name="text1" type="text" value="text1" size="20">

<br/><br/>
<span id="spnlabel" style="overflow:hidden">
-
</span>
<span id="spntext" style="overflow:hidden">
<input name="text2" type="text" value="text2" size="20">

</span>
</div>
</body>
</html>


Thanks.


PS. The logic seems strange, but I'll leave that alone... unless it
isn't doing whatever you expect it to. As it is, it may cause
flickering for some users.
 
B

bradwiseathome

That is incredible. Thanks! I just learned a lot. The bottom line is
that I need to show or hide a text box based on a selected option in a
list, and it works in IE6 and FireFox 1.0.2, so I'm set.

Thanks again!
 
R

RobG

Richard said:
<snip>

When the mark-up presented appears to XHTML what would suggest an HTML
doctype?

I took a punt that the OP was really after HTML.

It's probably reasonable to infer that the OP was attempting XHTML,
but there seems to be an idea spreading that closing empty tags is
desirable in HTML also - it will still validate OK as HTML 4 strict.

There is also no character encoding, title or closing form tag.
 
M

Michael Winter

On 07/05/2005 02:14, RobG wrote:

[snip]
there seems to be an idea spreading that closing empty tags is
desirable in HTML also - it will still validate OK as HTML 4 strict.

It will validate, yes. However it means something entirely different.
There is also no character encoding [...]

To be fair to the OP, it is preferable to send the character encoding in
the Content-Type HTTP header. You have no way of knowing if the charset
parameter has been specified.

Mike
 
R

Richard Cornford

RobG wrote:
I took a punt that the OP was really after HTML.

Given the IE doesn't understand XHTML, HTML would probably be the OP's
best choice regardless of his intention.
It's probably reasonable to infer that the OP was
attempting XHTML, but there seems to be an idea
spreading that closing empty tags is desirable in
HTML also

Many notions that are apparently not harmful are able to freely
propagate. But HTML and XHTML are subject to detailed specification so
they can be understood at a technical level, and they can both be
objectively correct and incorrect. You will be hard pressed to find
anyone with a technical understanding of these mark-up languages
encouraging the mixing of the two styles.
- it will still validate OK as HTML 4 strict.

That depends a great deal on the context of the use of the slash at the
end of the tag. The SGML abbreviation '<br />' expands to '<br>>' ,
where the second chevron is text content following the BR element. The
abbreviated version will validate in contexts where text content would
be allowed, but would not validate if the element-terminating slash
implied the following text chevron in a context that did not allow text
content. The strict DTD has fewer contexts in which text is allowed than
the transition DTD.

Regardless of whether this mixed mark-up validates, it is unlikely that
the OP intended to insert a sequence of '>' characters into their page.
The fact that the majority of browsers do not follow the HTML
specification in this respect conceals the error, but it is still an
error to create mark-up that should be expected to produce results other
than those intended. And even browsers that do not handle the mark-up in
the way that they really should still expend additional effort in
disregarding what they perceive as a superfluous character in a tag.
Thus the folly in mixing mark-up styles should be pointed out when it is
observed, and discouraged.
There is also no character encoding, title or closing
form tag.

As Mike said, character encoding is handled by required HTTP headers so
the absence of an optional (and theoretically superfluous) META element
is not an error. Other obvious mark-up errors could be pointed out to
the OP, or the blanket recommendation to create valid mark-up provided
(though the ill-conceived use of XHTML style mark-up in HTML would need
to be pointed out separately as, as you observer, it will often
validate).

Richard.
 
T

Thomas 'PointedEars' Lahn

Richard said:
Many notions that are apparently not harmful are able to freely
propagate. But HTML and XHTML are subject to detailed specification so
they can be understood at a technical level, and they can both be
objectively correct and incorrect. You will be hard pressed to find
anyone with a technical understanding of these mark-up languages
encouraging the mixing of the two styles.

<rant>
Yes, I thought that, too, when reading the HTML Compatibility Guidelines
of the XHTML 1.0 Specification. They are flawed for exactly that reason.
</rant>


PointedEars
 
J

Jim Ley

<rant>
Yes, I thought that, too, when reading the HTML Compatibility Guidelines
of the XHTML 1.0 Specification. They are flawed for exactly that reason.
</rant>

The W3c is required to address all comments from the public, including
ones that arrive after it becomes a rec, rather than rant pointlessly
on usenet, (e-mail address removed) is the place to send your comments.

Jim.
 

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,767
Messages
2,569,572
Members
45,046
Latest member
Gavizuho

Latest Threads

Top