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

[Dan R Brown]

I have a large form that is generated dynamically in a jsp using xml / xslt. So, to
break up this form into several "tabbed" sections, I break up the form using <div>
tags. Each <div style="display:none"> can be displayed by setting the style attribute
to "display:", or hidden with "display:none". This gives the illusion that the person
filling out the form is switching from page to page...without the overhead of extra
hits on the server, since the entire page is already loaded on the client. It also has
the added advantage of being able to switch from section to section without any data
loss.

I have some simple javascript that changes the style attrs on the div tags (an onclick
event on the "tabs"), and this works fine.

Once the user finishes the form, 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+.

Any help would be great!
Thanks,
Dan

 

[Richard Cornford]

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

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]

Path: nntp.TheWorld.com!newsfeed.mathworks.com!kibo.news.demon.net!news.demon.co.uk!demon!not-for-mail
From: "Richard Cornford" <[email protected]>
Newsgroups: comp.lang.javascript
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: <[email protected]>
References: <[email protected]>
NNTP-Posting-Host: litotes.demon.co.uk
X-Trace: news.demon.co.uk 1059698886 15881 212.229.126.254 (1 Aug 2003 00:48:06 GMT)
X-Complaints-To: (e-mail address removed)
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.com comp.lang.javascript:417338

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.

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:none> 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...and 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

 

[Richard Cornford]

The reason for using the <div> tags is to hide, or show, sections
of the form to the user. Each <div> sections the form ...

<snip>

You said all that the first time.

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 ).
<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:hidden 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]

To you and IE, they may exist but to NS, they don't.

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>

 

[Dan R Brown]

Path: nntp.TheWorld.com!newsfeed.mathworks.com!irazu.switch.ch!switch.ch!npeer.de.kpn-eurorings.net!newsfeed.vmunix.org!uio.no!newsfeed1.uni2.dk!newsfeed101.telia.com!nf01.dk.telia.net!news104.dk.telia.net!not-for-mail
Sender: Lasse R. Nielsen@SUZIE
Newsgroups: comp.lang.javascript
Subject: Re: Problems with form elements that are hidden with <div style="display:none">
References: <[email protected]> <[email protected]>
From: Lasse Reichstein Nielsen <[email protected]>
Date: 01 Aug 2003 19:09:47 +0200
Message-ID: <[email protected]>
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.dk 7798 62.107.37.120
X-Complaints-To: Telia Stofa Abuse <[email protected]>
Xref: nntp.TheWorld.com comp.lang.javascript:417400

(e-mail address removed) (HikksNotAtHome) writes:

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

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]

Path: nntp.TheWorld.com!newsfeed.mathworks.com!btnet-peer0!btnet-feed5!btnet!news.btopenworld.com!not-for-mail
From: "Richard Cornford" <[email protected]>
Newsgroups: comp.lang.javascript
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: <[email protected]>
References: <[email protected]> <[email protected]> <[email protected]>
NNTP-Posting-Host: host81-130-28-15.in-addr.btopenworld.com
X-Trace: sparta.btinternet.com 1059755286 11053 81.130.28.15 (1 Aug 2003 16:28:06 GMT)
X-Complaints-To: (e-mail address removed)
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.com comp.lang.javascript:417396

You said all that the first time.
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:hidden 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.

I will try the visibility:hidden 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]

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

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.

Is this a problem in later versions as well? ...

<snip>

No, it has been fixed.

Richard.

 

[Jim Ley]

My inclination is not to bother the user about whether their browser is
adequate or not.

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

Jim.

 

[Dom Leonard]

Jim Ley wrote:
I can't find anything in

Bugzilla on this, has the OP told them?

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

 

[Dom Leonard]

I will try the visibility:hidden 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 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="0px";
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]

Indeed, I wasn't being entirely serious. ...

<snip>

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

Richard.

 

[Dom Leonard]

"Dom Leonard" ...


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

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:none", 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:hidden" 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><title>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.getElementById("test");
switch(lastMethod=method) {
case "classNone":
case "classHeight":
div.className=method;
break;
case "none":
div.style.display="none";
break;
case "height":
div.style.height="1px";
div.style.overflow="hidden";
}
}
function show() {
var div=document.getElementById("test");
switch(lastMethod) {
case "classNone":
case "classHeight":
div.className=""; break;
case "none":
div.style.display="block"; break;
case "height":
div.style.height="auto";
div.style.overflow="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.html">

<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');return false";>className
(none)</a>, or
<a href="#" onclick="hide('none');return false;">style
display:none</a>, or<br>
<a href="#" onclick="hide('classHeight');return false";>className
(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="enquire();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>