<input type='image'> ... IE fails to pass value while Mozilla and Netsacpe works
John Everett
I have found that the <input type=image'> passes a value when
interpeted with Netscape or Mozilla but NOT with IE.
Consider the following:
HTML page passing a form...
<html>
<head>
</head>
<body>
<form name='test' action='test.cgi' method='post'>
<input type='image' name='test' value='1' src='../images/blue_bullet.jpg'>
</from>
</body>
</html>
Perl cgi script catching the form (test.cgi)...
#!/usr/bin/perl
use CGI;
my $page = new CGI;
my $test_value = $page -> param('test');
print $page -> header();
print "test value: $test_value <br>";
Both Netscape and Mozilla and print $test_value
as "1" while IE prints it as an empty string.
Why does the HTML page not pass the input value
to the cgi script?
Any help would be great!
Thanks in advance.
John
--
PLEASE NOTE: comp.infosystems.www.authoring.cgi is a
SELF-MODERATED newsgroup. aa.net and boutell.com are
NOT the originators of the articles and are NOT responsible
for their content.
HOW TO POST to comp.infosystems.www.authoring.cgi:
http://www.thinkspot.net/ciwac/howtopost.html
Alan J. Flavell
> <input type='image' name='test' value='1' src='../images/blue_bullet.jpg'>
Check the HTML specification.
> print "test value: $test_value <br>";
In this kind of diagnostic situation, I'd recommend that you get
accustomed to printing out the entire submission parameters. If you
want it pretty, you can use CGI.pm's Dump() method. If you want to
see the nitty details, then something like
foreach my $name (sort keys (%ENV)) {
...
}
and print out each $name with its $ENV{$name} in whatever format you
want. (Don't forget to escapeHTML() before printing, if you're trying
to produce a text/html report).
> Both Netscape and Mozilla and print $test_value
> as "1"
Interesting, I wasn't aware of that. It sounds as if they decided to
DWIM for the benefit of folks who don't read the specifications.
> while IE prints it as an empty string.
More likely it's undefined - and you didn't have Perl warnings enabled
(bad!). Read the comp.lang.perl.misc posting guidelines for details
of how to get Perl to help you to help yourself.
> Why does the HTML page not pass the input value to the cgi script?
What does the HTML specification say about the type=image control at
http://www.w3.org/TR/html401/interact/forms.html#h-17.4.1 ?
I don't see anything about submitting the "value" attribute.
good luck
John Everett
Thanks for the insight.
I have already checked all of the parameters passed
with the following:
@passed_parameters = $page -> param;
foreach $passed ( @passed_parameters )
{
print "$passed -> " . $page -> param($passed) . "<br>\n";
}
Mozilla and Netsape yield:
passed parameters:
test.x -> 16
test.y -> 16
test -> 1
while IE yield:
passed parameters:
test.x -> 16
test.y -> 16
Thanks for writing back.
Guess it is just a Mozilla/Netscape expansion (or corruption )
of the standard.
Regards,
John
Jukka K. Korpela
> Guess it is just a Mozilla/Netscape expansion (or corruption )
> of the standard.
No, violation. The HTML specifications clearly define what the form
data set consists of. A browser must not add anything to it.
--
Yucca, http://www.cs.tut.fi/~jkorpela/
nob...@mail.com
> john_k_...@hotmail.com (John Everett) wrote:
>
> > Guess it is just a Mozilla/Netscape expansion (or corruption )
> > of the standard.
>
> No, violation.
Make that: no violation.
> The HTML specifications clearly define what the form
> data set consists of.
Surely, if they had been clear you would not have misread them :-).
Mozilla/Netscape are acting in accorance with the standard.
IE is not.
No big supprise there.
> A browser must not add anything to it.
Or subtract.
"Just another bug in IE".
Jukka K. Korpela
> Mozilla/Netscape are acting in accorance with the standard.
>
> IE is not.
Your message was somewhat obscure message, but you seem to have a point,
though implicitly.
Let's start from what the HTML specification says at
http://www.w3.org/TR/html4/interact/forms.html#h-17.13.3.2
"A form data set is a sequence of control-name/current-value pairs
constructed from successful controls."
Following the links, we find this:
"Every successful control has its control name paired with its current
value as part of the submitted form data set."
and
"The control's "current value" is first set to the initial value."
and
"In general, a control's "initial value" may be specified with the control
element's value attribute." (exceptions to this don't apply to this case)
Hence, it seems that when we have
<input type='image' name='test' value='1' src='../images/blue_bullet.jpg'>
the control with name 'test' is successful, since it has a current value,
namely '1', assigned to it as initial value. Hence, test=1 shall be
included into the form data set. However, it is a bit unclear whether this
shall take place always or only when this element is used to submit the
form. The specification says: "If a form contains more than one submit
button, only the activated submit button is successful." But it's not
clear whether "graphical submit buttons" belong to the category of submit
buttons.
This is largely theoretical only, since no user action can affect what the
submitted value is (except via scripting). It's basically static data
(and most browsers don't actually include it). But it's an odd feature in
the specification.
--
Yucca, http://www.cs.tut.fi/~jkorpela/
nob...@mail.com
> nob...@mail.com wrote:
>
> > Mozilla/Netscape are acting in accorance with the standard.
> >
> > IE is not.
>
> Your message was somewhat obscure message,
Sorry - my first attempt was lost because my NNTP server didn't
realise this newsgroup is moderated.
> but you seem to have a point, though implicitly.
>
> Let's start from what the HTML specification says at
> "A form data set is a sequence of control-name/current-value pairs
> constructed from successful controls."
> "Every successful control has its control name paired with its current
> value as part of the submitted form data set."
> "The control's "current value" is first set to the initial value."
> "In general, a control's "initial value" may be specified with the control
> element's value attribute." (exceptions to this don't apply to this case)
> "If a form contains more than one submit button, only the activated submit
> button is successful."
So if a "graphical submit button" is a "submit button" then IE is
wrong and netscape is right.
> But it's not clear whether "graphical submit buttons" belong to the
> category of submit buttons.
Well by natural usage of the English langauage objects of the category
"<adjective> <nown>" can be assumed to belong to the category "<nown>"
unless there is some particular reason to suppose otherwise.
Furthermore, where the standard says of <input type='image'> that it
"Creates a graphical submit button", "submit button" is a hyperlink to
the definition of the term "submit button". This further re-enforces
the null-hypothesis that that "graphical submit button" is indeed a
subcategory of "submit button".
> This is largely theoretical only, since no user action can affect what the
> submitted value is (except via scripting). It's basically static data
It is common in HTML forms to have several submit buttons with the
same control name and use the value returned to determine which was
successful.
> (and most browsers don't actually include it).
Out of interest, what other browsers (that claim HTML4 compliance)
implement <input type='image'> incorrectly?
> But it's an odd feature in the specification.
No, if graphical submit buttons behaved uneccessarily differently from
submit buttons that would be odd. Particularly when you consider that
on a non-graphical UA graphical submit buttons are no different from
any other submit buttons!
Of course we could clear up any ambiguity by always using <button>.
Unfortunately IE's implementation of <button> is even more in
violation of the standard than its implementation of <input
type='image'>.