Problems with form elements that are hidden with <div style="display:none">

**Richard Cornford** · Jul 20 '05, 09:28 AM

Re: Problems with form elements that are hidden with <div style="dis play:none" >

"Dan R Brown" <drb@TheWorld.c om> wrote in message
news:bgb8s6$vdp $1@pcls4.std.co m...
<snip>[color=blue]
>... , the click submit and in theory the entire form is
>submitted. The problem is when using NS6.x browsers
>( a requirement for this project ), any form field
>that resides in a hidden div tag
>(<div style="display: none">) is
>treated as if it does not exist.
>This is not a problem with IE6+ and NS7.x+.[/color]

I suppose that I could boot the machine I have with Netscape 6.2
installed, create a test page and find out for myself but...

Are you saying that the form elements contained within DIV elements that
have style attributes that assign a display:none; property are not
submitted with the form or that the DIVs that have their style
properties set to 'none' at the point of submitting the form are not
included (or both)?

If the problem is associated with the initial setting of the style
attributes in the HTML then you probably should not have been doing that
anyway [1]. It would be possible to have the XSLT create an onload
handling function that set the initial display state of the DIVs on the
page.

If the problem is with the state of the display properties when the form
is submitted then it should be possible to reveal all the DIVs on the
page when the submit button is presses.

[1] The reason for using JavaScript to set the initial display
properties is that you need JavaScript to be available in order to
reveal them again. If the CSS sets the initial display states then any
style="display: none;" elements will just never be available in the
absence of JavaScript on the client.

The extent to which that is important may depend on the exact wording of
your specification. You say that the specification requires support for
Netscape 6.x. If your spec actually states a requirement to support
"JavaScript enabled Netscape 6.x" (or Net 6 in its default
configuration, or something similar) then you will be able to make a
JavaScript dependent site and meet the specification. However, if the
specification only states a requirement to support Netscape 6.x (along
with any other browsers included) then it could be reasonably
interpreted as requiring support for Netscape 6.x in any and all of its
user configurable states. Those user configurable states of course
include the option of turning JavaScript off (and quite a lot else
besides).

My experience of specifications that state a range of required browser
support is that they are backed by a contract with a client. If the
contract specifies browsers (only) then it would not be unreasonable for
a client, on discovering that they have been presented with a JavaScript
dependent site, to come back and say, "You knew that the browser was
configurable when you agreed to support it, only supporting the browser
in *one* of its configurations is not acceptable, go back and fix it or
we won't be paying.". And if they did, I think that they would be able
to make a good case in court, if it came to that.

Richard.

**Dan R Brown** · Jul 20 '05, 09:28 AM

Re: Problems with form elements that are hidden with <div style="dis play:none" >

Richard Cornford <Richard@litote s.demon.co.uk> wrote:[color=blue]
> Path: nntp.TheWorld.c om!newsfeed.mat hworks.com!kibo .news.demon.net !news.demon.co. uk!demon!not-for-mail
> From: "Richard Cornford" <Richard@litote s.demon.co.uk>
> Newsgroups: comp.lang.javas cript
> Subject: Re: Problems with form elements that are hidden with <div style="display: none">
> Date: Fri, 1 Aug 2003 01:48:03 +0100
> Lines: 62
> Message-ID: <bgcdc5$fg9$1$8 302bc10@news.de mon.co.uk>
> References: <bgb8s6$vdp$1@p cls4.std.com>
> NNTP-Posting-Host: litotes.demon.c o.uk
> X-Trace: news.demon.co.u k 1059698886 15881 212.229.126.254 (1 Aug 2003 00:48:06 GMT)
> X-Complaints-To: abuse@demon.net
> NNTP-Posting-Date: Fri, 1 Aug 2003 00:48:06 +0000 (UTC)
> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
> X-Priority: 3
> X-Newsreader: Microsoft Outlook Express 6.00.2800.1106
> X-MSMail-Priority: Normal
> Xref: nntp.TheWorld.c om comp.lang.javas cript:417338[/color]
[color=blue]
> "Dan R Brown" <drb@TheWorld.c om> wrote in message
> news:bgb8s6$vdp $1@pcls4.std.co m...
> <snip>[color=green]
>>... , the click submit and in theory the entire form is
>>submitted. The problem is when using NS6.x browsers
>>( a requirement for this project ), any form field
>>that resides in a hidden div tag
>>(<div style="display: none">) is
>>treated as if it does not exist.
>>This is not a problem with IE6+ and NS7.x+.[/color][/color]
[color=blue]
> I suppose that I could boot the machine I have with Netscape 6.2
> installed, create a test page and find out for myself but...[/color]
[color=blue]
> Are you saying that the form elements contained within DIV elements that
> have style attributes that assign a display:none; property are not
> submitted with the form or that the DIVs that have their style
> properties set to 'none' at the point of submitting the form are not
> included (or both)?[/color]
[color=blue]
> If the problem is associated with the initial setting of the style
> attributes in the HTML then you probably should not have been doing that
> anyway [1]. It would be possible to have the XSLT create an onload
> handling function that set the initial display state of the DIVs on the
> page.[/color]
[color=blue]
> If the problem is with the state of the display properties when the form
> is submitted then it should be possible to reveal all the DIVs on the
> page when the submit button is presses.[/color]
[color=blue]
> [1] The reason for using JavaScript to set the initial display
> properties is that you need JavaScript to be available in order to
> reveal them again. If the CSS sets the initial display states then any
> style="display: none;" elements will just never be available in the
> absence of JavaScript on the client.[/color]
[color=blue]
> The extent to which that is important may depend on the exact wording of
> your specification. You say that the specification requires support for
> Netscape 6.x. If your spec actually states a requirement to support
> "JavaScript enabled Netscape 6.x" (or Net 6 in its default
> configuration, or something similar) then you will be able to make a
> JavaScript dependent site and meet the specification. However, if the
> specification only states a requirement to support Netscape 6.x (along
> with any other browsers included) then it could be reasonably
> interpreted as requiring support for Netscape 6.x in any and all of its
> user configurable states. Those user configurable states of course
> include the option of turning JavaScript off (and quite a lot else
> besides).[/color]
[color=blue]
> My experience of specifications that state a range of required browser
> support is that they are backed by a contract with a client. If the
> contract specifies browsers (only) then it would not be unreasonable for
> a client, on discovering that they have been presented with a JavaScript
> dependent site, to come back and say, "You knew that the browser was
> configurable when you agreed to support it, only supporting the browser
> in *one* of its configurations is not acceptable, go back and fix it or
> we won't be paying.". And if they did, I think that they would be able
> to make a good case in court, if it came to that.[/color]
[color=blue]
> Richard.[/color]

The reason for using the <div> tags is to hide, or show, sections of the form to the
user. Each <div> sections the form based on a top, or category, related to the
information. When the user first navigates to the page a "general" section is
displayed, while all other sections are hidden from view (the xslt sets the correct
styles in the <div> tags. If the user wishes to see another section (i.e. xyz
settings), they click on the "xyz settings" tab / button. There is javascript
associated with the page that will set the style of the the previously viewed section
to hidden, and then display the "xyz settings" section of the form. This all works
fine.

What does not work (using NS6.x) is that when the form is submitted, any form element
that is hidden from view within <div style=display:n one> tags, do not get sent (post or
get...it doesn't matter). NS6.x treats those form elements as if they do not exist on
the page, when in fact they do.

The suggestion of exposing all of the <div> tags, prior to submit works, but it's a
major eyesore that is not accepatble in our product ( which is not a web site, but a
browser based user interface for configurations ).

As far as the specification goes, NS6.x is a requirement...a nd javascript must be
enabled. The problem is not with the spec...it's with how NS6.x handles a css element.

Thanks for your reply
Dan

**HikksNotAtHome** · Jul 20 '05, 09:28 AM

Re: Problems with form elements that are hidden with <div style="dis play:none" >

In article <bge2ho$7n1$1@p cls4.std.com>, Dan R Brown <drb@shell01.Th eWorld.com>
writes:
[color=blue]
>What does not work (using NS6.x) is that when the form is submitted,
>any form element that is hidden from view within <div style=display:n one>
>tags, do not get sent (post or get...it doesn't matter). NS6.x treats those
>form elements as if they do not exist on the page, when in fact they do.[/color]

To you and IE, they may exist but to NS, they don't.
[color=blue]
>The suggestion of exposing all of the <div> tags, prior to submit works, but
>it's a major eyesore that is not accepatble in our product ( which is not a[/color]
web[color=blue]
>site, but a browser based user interface for configurations ).
>
>As far as the specification goes, NS6.x is a requirement...a nd javascript
>must be enabled. The problem is not with the spec...it's with how NS6.x
>handles a css element.[/color]

Use a hidden form that gets submitted. onchange of every field, have it set its
corresponding hidden counterpart. Then submit the hidden fields form.

--
Randy
All code posted is dependent upon the viewing browser
supporting the methods called, and Javascript being enabled.

**Richard Cornford** · Jul 20 '05, 09:28 AM

Re: Problems with form elements that are hidden with <div style="dis play:none" >

"Dan R Brown" <drb@shell01.Th eWorld.com> wrote in message
news:bge2ho$7n1 $1@pcls4.std.co m...
<snip>[color=blue]
> The reason for using the <div> tags is to hide, or show, sections
>of the form to the user. Each <div> sections the form ...[/color]
<snip>

You said all that the first time.
[color=blue]
> The suggestion of exposing all of the <div> tags, prior to submit[/color]
works,[color=blue]
>but it's a major eyesore that is not accepatble in our product ( which[/color]
is[color=blue]
>not a web site, but a browser based user interface for[/color]
configurations ).
<snip>

If the DIVs must be display:block for the submission to include their
contents then you have not choice but make that setting. However, how
does visibility:hidd en effect the submissions, and is there any
potential for setting z-index and stacking all of the DIVs under the one
that you want to show at the end?

Richard.

**Lasse Reichstein Nielsen** · Jul 20 '05, 09:28 AM

Re: Problems with form elements that are hidden with <div style="dis play:none" >

hikksnotathome@ aol.com (HikksNotAtHome ) writes:
[color=blue]
> In article <bge2ho$7n1$1@p cls4.std.com>, Dan R Brown <drb@shell01.Th eWorld.com>
> writes:
>[color=green]
> >What does not work (using NS6.x) is that when the form is submitted,
> >any form element that is hidden from view within <div style=display:n one>
> >tags, do not get sent (post or get...it doesn't matter). NS6.x treats those
> >form elements as if they do not exist on the page, when in fact they do.[/color]
>
> To you and IE, they may exist but to NS, they don't.[/color]

Then NS6 is broken. The form elements exists structurally in the document.
How CSS makes them look should not be important.

Is this a problem in later versions as well? I don't have NS6
available to check the problem right now, but I can't see the problem
in Mozilla FB 0.6.

Setting either the form, or a div containing an input, to display:none
will still include the element in the submission. This code puts bar=foo
in the resulting address
---
<form action="" method="GET" id="foo">
<div style="display: none">
<input type="text" value="foo" name="bar">
</div>
<input type="submit">
</form>
---

/L
--
Lasse Reichstein Nielsen - lrn@hotpop.com
Art D'HTML: <URL:http://www.infimum.dk/HTML/randomArtSplit. html>
'Faith without judgement merely degrades the spirit divine.'

**Dan R Brown** · Jul 20 '05, 09:28 AM

Re: Problems with form elements that are hidden with <div style="dis play:none" >

Lasse Reichstein Nielsen <lrn@hotpop.com > wrote:[color=blue]
> Path: nntp.TheWorld.c om!newsfeed.mat hworks.com!iraz u.switch.ch!swi tch.ch!npeer.de .kpn-eurorings.net!n ewsfeed.vmunix. org!uio.no!news feed1.uni2.dk!n ewsfeed101.teli a.com!nf01.dk.t elia.net!news10 4.dk.telia.net! not-for-mail
> Sender: Lasse R. Nielsen@SUZIE
> Newsgroups: comp.lang.javas cript
> Subject: Re: Problems with form elements that are hidden with <div style="display: none">
> References: <bge2ho$7n1$1@p cls4.std.com> <20030801122735 .09955.00001056 @mb-m21.aol.com>
> From: Lasse Reichstein Nielsen <lrn@hotpop.com >
> Date: 01 Aug 2003 19:09:47 +0200
> Message-ID: <n0eti9t0.fsf@h otpop.com>
> User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Native Windows TTY Support (Windows))
> MIME-Version: 1.0
> Content-Type: text/plain; charset=us-ascii
> Lines: 36
> NNTP-Posting-Host: 62.107.37.120
> X-Trace: 1059757503 news.stofanet.d k 7798 62.107.37.120
> X-Complaints-To: Telia Stofa Abuse <abuse@stofa.dk >
> Xref: nntp.TheWorld.c om comp.lang.javas cript:417400[/color]
[color=blue]
> hikksnotathome@ aol.com (HikksNotAtHome ) writes:[/color]
[color=blue][color=green]
>> In article <bge2ho$7n1$1@p cls4.std.com>, Dan R Brown <drb@shell01.Th eWorld.com>
>> writes:
>>[color=darkred]
>> >What does not work (using NS6.x) is that when the form is submitted,
>> >any form element that is hidden from view within <div style=display:n one>
>> >tags, do not get sent (post or get...it doesn't matter). NS6.x treats those
>> >form elements as if they do not exist on the page, when in fact they do.[/color]
>>
>> To you and IE, they may exist but to NS, they don't.[/color][/color]
[color=blue]
> Then NS6 is broken. The form elements exists structurally in the document.
> How CSS makes them look should not be important.[/color]
[color=blue]
> Is this a problem in later versions as well? I don't have NS6
> available to check the problem right now, but I can't see the problem
> in Mozilla FB 0.6.[/color]
[color=blue]
> Setting either the form, or a div containing an input, to display:none
> will still include the element in the submission. This code puts bar=foo
> in the resulting address
> ---
> <form action="" method="GET" id="foo">
> <div style="display: none">
> <input type="text" value="foo" name="bar">
> </div>
> <input type="submit">
> </form>
> ---[/color]
[color=blue]
> /L
> --
> Lasse Reichstein Nielsen - lrn@hotpop.com
> Art D'HTML: <URL:http://www.infimum.dk/HTML/randomArtSplit. html>
> 'Faith without judgement merely degrades the spirit divine.'[/color]

It work fine in NS7.x, and with Mozilla 1.2 and up ( haven't tried it with any earlier
versions ).

Thanks,
Dan

**Dan R Brown** · Jul 20 '05, 09:28 AM

Re: Problems with form elements that are hidden with <div style="dis play:none" >

Richard Cornford <richard@litote s.demon.co.uk> wrote:[color=blue]
> Path: nntp.TheWorld.c om!newsfeed.mat hworks.com!btne t-peer0!btnet-feed5!btnet!new s.btopenworld.c om!not-for-mail
> From: "Richard Cornford" <richard@litote s.demon.co.uk>
> Newsgroups: comp.lang.javas cript
> Subject: Re: Problems with form elements that are hidden with <div style="display: none">
> Date: Fri, 1 Aug 2003 16:28:06 +0000 (UTC)
> Organization: BT Openworld
> Lines: 26
> Message-ID: <bge4em$apd$1@s parta.btinterne t.com>
> References: <bgb8s6$vdp$1@p cls4.std.com> <bgcdc5$fg9$1$8 302bc10@news.de mon.co.uk> <bge2ho$7n1$1@p cls4.std.com>
> NNTP-Posting-Host: host81-130-28-15.in-addr.btopenworl d.com
> X-Trace: sparta.btintern et.com 1059755286 11053 81.130.28.15 (1 Aug 2003 16:28:06 GMT)
> X-Complaints-To: news-complaints@list s.btinternet.co m
> NNTP-Posting-Date: Fri, 1 Aug 2003 16:28:06 +0000 (UTC)
> X-Newsreader: Microsoft Outlook Express 6.00.2600.0000
> X-MSMail-Priority: Normal
> X-Priority: 3
> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
> Xref: nntp.TheWorld.c om comp.lang.javas cript:417396[/color]
[color=blue]
> "Dan R Brown" <drb@shell01.Th eWorld.com> wrote in message
> news:bge2ho$7n1 $1@pcls4.std.co m...
> <snip>[color=green]
>> The reason for using the <div> tags is to hide, or show, sections
>>of the form to the user. Each <div> sections the form ...[/color]
> <snip>[/color]
[color=blue]
> You said all that the first time.[/color]
[color=blue][color=green]
>> The suggestion of exposing all of the <div> tags, prior to submit[/color]
> works,[color=green]
>>but it's a major eyesore that is not accepatble in our product ( which[/color]
> is[color=green]
>>not a web site, but a browser based user interface for[/color]
> configurations ).
> <snip>[/color]
[color=blue]
> If the DIVs must be display:block for the submission to include their
> contents then you have not choice but make that setting. However, how
> does visibility:hidd en effect the submissions, and is there any
> potential for setting z-index and stacking all of the DIVs under the one
> that you want to show at the end?[/color]
[color=blue]
> Richard.[/color]

I will try the visibility:hidd en to see if that works. Using z order for stacking has
it's draw backs in that when the page loads in, you see the various layers stacking
(probably due to the size of the page and the number of layers).

Thanks,
Dan

**Richard Cornford** · Jul 20 '05, 09:29 AM

Re: Problems with form elements that are hidden with <div style="dis play:none" >

"Lasse Reichstein Nielsen" <lrn@hotpop.com > wrote in message
news:n0eti9t0.f sf@hotpop.com.. .
<snip>[color=blue][color=green]
>>To you and IE, they may exist but to NS, they don't.[/color]
>
>Then NS6 is broken. The form elements exists structurally in
>the document. How CSS makes them look should not be important.[/color]

Netscape 6 was based on a pre-release Mozilla 0.9 and is one of the
buggiest browsers ever released. Requiring support for Net 6 seems like
an arbitrary decision based on the version numbers rather than any
understanding of the browsers in question.

I have just been testing this problem on Net 6 and the display property
does not effect the DOM. The DIVs and contained Input elements are all
there, and the elements are all in the form.elements collection;
readable, writeable, with their disabled properties set to false and so
on. Nothing accessible to JavaScript that would suggest that they should
not be successful controls. Yet if they are within a display:none block
they are not submitted.
[color=blue]
>Is this a problem in later versions as well? ...[/color]
<snip>

No, it has been fixed.

Richard.

**Jim Ley** · Jul 20 '05, 09:29 AM

Re: Problems with form elements that are hidden with <div style="dis play:none" >

On Sat, 2 Aug 2003 15:59:59 +0100, "Richard Cornford"
<Richard@litote s.demon.co.uk> wrote:
[color=blue]
>"Jim Ley" <jim@jibbering. com> wrote in message
>news:3f2a9669. 25520105@news.c is.dfn.de...
><snip>[color=green]
>>Or tell the browser to sort itself out, and only support
>>standards conforming one's... oh no, people only do that
>>when IE is at fault...[/color]
>
>My inclination is not to bother the user about whether their browser is
>adequate or not.[/color]

Indeed, I wasn't being entirely serious. I can't find anything in
Bugzilla on this, has the OP told them?

Jim.
--
comp.lang.javas cript FAQ - http://jibbering.com/faq/

**Dom Leonard** · Jul 20 '05, 09:29 AM

Re: Problems with form elements that are hidden with <div style="dis play:none" >

Jim Ley wrote:
I can't find anything in[color=blue]
> Bugzilla on this, has the OP told them?
>[/color]

There is no need. See current mozilla bug-100533, fixed bug-60893, fixed
bug-34297

**Dom Leonard** · Jul 20 '05, 09:30 AM

Re: Problems with form elements that are hidden with <div style="dis play:none" >

Dan R Brown wrote:
[color=blue]
> I will try the visibility:hidd en to see if that works. Using z order for stacking has
> it's draw backs in that when the page loads in, you see the various layers stacking
> (probably due to the size of the page and the number of layers).
>[/color]
Thanks for the post Dan, and all discussion. I hadn't realised
submitting <display:none > fields was a problem with NS6.xx - Opera up to
7.11 at least seems to have similar problems. As per group discussion
visibility and z-index work around the problem, and I have used them.

The reason for the late comment (and sorry I missed discussion earlier
in the week) is that if between a rock and a hard place you might like
to try

style.height="0 px";
style.overflow= "hidden";

as an alternative to display:none in workaround. It was one of the
alternatives I tested and, without saying it will always succeed, met
with success under NS6.01 and up, IE5,6, Mozilla and Opera 7.

Dom

**Richard Cornford** · Jul 20 '05, 09:30 AM

Re: Problems with form elements that are hidden with <div style="dis play:none" >

"Jim Ley" <jim@jibbering. com> wrote in message
news:3f2c043e.5 8289185@news.ci s.dfn.de...
<snip>[color=blue][color=green][color=darkred]
>>>Or tell the browser to sort itself out, and only support
>>>standards conforming one's... oh no, people only do that
>>>when IE is at fault...[/color]
>>
>>My inclination is not to bother the user about whether
>>their browser is adequate or not.[/color]
>
> Indeed, I wasn't being entirely serious. ...[/color]
<snip>

Ahh. I thought I detected a hint of irony ;-)

Richard.

**Dom Leonard** · Jul 20 '05, 09:30 AM

Re: Problems with form elements that are hidden with <div style="dis play:none" >

Richard Cornford wrote:[color=blue]
> "Dom Leonard" ...
> <snip>
>[color=green]
>>... . I hadn't realised submitting <display:none > fields was
>>a problem with NS6.xx - Opera up to 7.11 at least seems to
>>have similar problems. ...[/color]
>
> <snip>
>
> I did not find this problem in Opera 7. The test page I posted (without
> the onsubmit handler) seems to have no problem sending the display:none
> fields (at least using a get request) in Opera 7.0b1, 7.02 or 7.11.
>[/color]

The problem encountered was not with Opera submission, which I've tested
works using a post request as well, but with the data sent.

To go into detail, "similar problems" was in reference to failures
observed with form reset and script enquiry. Under Opera form reset
doesn't appear to reset fields within display:none containers, and
script enquiry of their values may be incorrect. The difference between
failure to submit form data, and submitting data that need not reflect
actions taken by the user is what I called "similar". I appreciate that
independant confirmation of these kinds of failures is important and
list the test page below. Initially I found reset problems using class
name switching so have included that as an option.

In regards the hack of substituting "height:0px ; overflow:hidden " for
"display:no ne", testing in conjuction with the above showed that
although successful under IE5.0, it does not work under IE6. The near
substitute of "height:1px ; overflow:hidden ; visibility:hidd en" appears
to work as written, but I can only indicate that it is last resort kind
of code, and if needed, should be taken "as is" for further testing.

Regards,
Dom

=======
<html><head><ti tle>Form test</title>
<style type="text/css">
..classNone {
display:none;
}
..classHeight {
height: 0px;
overflow: hidden;
}
</style>
<script type="text/javascript">
var lastMethod="";
function hide(method) {
var div;
if(lastMethod)
return; // already hidden;
div=document.ge tElementById("t est");
switch(lastMeth od=method) {
case "classNone" :
case "classHeigh t":
div.className=m ethod;
break;
case "none":
div.style.displ ay="none";
break;
case "height":
div.style.heigh t="1px";
div.style.overf low="hidden";
}
}
function show() {
var div=document.ge tElementById("t est");
switch(lastMeth od) {
case "classNone" :
case "classHeigh t":
div.className=" "; break;
case "none":
div.style.displ ay="block"; break;
case "height":
div.style.heigh t="auto";
div.style.overf low="visible";
}
lastMethod=""; // re-arm
}
function enquire() {
alert("check1 " + document.forms. testForm.check1 .checked
+ ", text1 " + document.forms. testForm.text1. value);
}
</script></head><body>

<form name="testForm" action="test.ht ml">

<div id="test">
<input type="checkbox" name="check1"> (check1)<br>
<input type="text" name="text1" size="40"> (text1)
</div>

<input type="reset" value="Reset">
<input type="submit" value="Submit">
<p>
Hide by<br>
<a href="#" onclick="hide(' classNone');ret urn false";>classNa me
(none)</a>, or
<a href="#" onclick="hide(' none');return false;">style
display:none</a>, or<br>
<a href="#" onclick="hide(' classHeight');r eturn false";>classNa me
(height)</a>, or
<a href="#" onclick="hide(' height');return false;">style
height:1px</a>; or<br>
<a href="#" onclick="show() ;return false">Show</a> or<br>
<a href="#" onclick="enquir e();return false;">Enquire </a><br>
</p>
<p>
NS6.xx doesn't submit from inside display:none</p>
<p>
Opera 7.03, 7.11 fails to reset check box or text within display:none.
Script enquiry for check box values within display:none returns false.
</p>
<p>Whilst IE5 hides for "height:0px ;", IE6 fails for same setting.
</p>
</form>
</body></html>

Problems with form elements that are hidden with <div style="display:none">

Problems with form elements that are hidden with <div style="display:none">

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment