468,549 Members | 2,219 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 468,549 developers. It's quick & easy.

JavaScript Document Code Not Cross Platform


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.visibili ty='visible';
}
else
{
document.getElementById('text2').style.visibility= 'hidden';
document.getElementById('spnlabel').style.visibili ty='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.

Jul 23 '05 #1
8 1571
bradwiseath...@hotmail.com wrote:
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[i].selected){
alert(selectVal[i].value + ' selected'); // Purely de-bug...
...

if (selectVal.value == 'Item1')
becomes:

if (selectVal[i].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.visibili ty='visible';
}
else
{
document.getElementById('text2').style.visibility= 'hidden';
document.getElementById('spnlabel').style.visibili ty='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">
<input name="text1" id="text1" ... >
<br/><br/>
<span id="spnlabel" style="overflow:hidden">
-
</span>
<span id="spntext" style="overflow:hidden">
<input name="text2" type="text" value="text2" size="20">
<input name="text2" id="text2" ... >
</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.
--
Rob

Jul 23 '05 #2
RobG wrote:
bradwiseath...@hotmail.com wrote: <snip> 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">

<snip>
</select>
<br/><br/>

<snip>

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

Richard.
Jul 23 '05 #3
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!

Jul 23 '05 #4
Richard Cornford wrote:
RobG wrote:
bradwiseath...@hotmail.com wrote:


<snip>
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">


<snip>
</select>
<br/><br/>


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

--
Rob
Jul 23 '05 #5
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

--
Michael Winter
Replace ".invalid" with ".uk" to reply by e-mail.
Jul 23 '05 #6
RobG wrote:
<snip>
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.
Jul 23 '05 #7
Richard Cornford wrote:
RobG wrote:
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.


<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
--
There are two possibilities: Either we are alone in the
universe or we are not. Both are equally terrifying.
-- Arthur C. Clarke
Jul 23 '05 #8
On Sun, 15 May 2005 18:03:00 +0200, Thomas 'PointedEars' Lahn
<Po*********@web.de> wrote:
<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, ww*************@w3.org is the place to send your comments.

Jim.
Jul 23 '05 #9

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

6 posts views Thread by Andy Fish | last post: by
2 posts views Thread by Halldor Isak Gylfason | last post: by
9 posts views Thread by MStepansky | last post: by
7 posts views Thread by harish.mallipeddi | last post: by
136 posts views Thread by Matt Kruse | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.