Richard Cornford <Richard@litotes.demon.co.uk> wrote:[color=blue]
> Path: nntp.TheWorld.com!newsfeed.mathworks.com!kibo.news .demon.net!news.demon.co.uk!demon!not-for-mail
> From: "Richard Cornford" <Richard@litotes.demon.co.uk>
> 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: <bgcdc5$fg9$1$8302bc10@news.demon.co.uk>
> References: <bgb8s6$vdp$1@pcls4.std.com>
> 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:
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.com comp.lang.javascript
:417338[/color]
[color=blue]
> "Dan R Brown" <drb@TheWorld.com> wrote in message
> news:bgb8s6$vdp$1@pcls4.std.com...
> <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: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
