Not all values posted with a form in IE
I am, hypothetically ( 🙂 ) working on an e-commerce site, and the other day I discovered that IE doesn’t post all values with a form.
Imagine a list of articles with a buy button on each row. Basically, what it needs to know is the id of the article to be bought and the quantity. My initial idea was to have one input element for quantity and one input type="image" button, with the article id as a value, used to post the form. Basically, I felt that an extra hidden element would be just superfluous. For example:
<form action="somewhere.php" method="get">
<input type="text" name="quantity" value="1">
<input type="image" name="buy" src="images/buy.png" alt="Buy" value="article-57">
</form>
The expected result in the query string should be:
?quantity=1&buy.x=&buy.y=&buy=article-57
But in IE 6 nd IE 7, it’s;
?quantity=1&buy.x=37&buy.y=15
Quite weird, isn’t it? And from what I seen, this only applies to input type="image" elements. What’s extra annoying is that it sends its x and y values, which are the actual coordinates where you clicked on the button. Why the IE team would think that the coordinates of the click is more important than the actual value is beyond me… 🙂
This happens cross browser too i believe!
On OSX Firefox and Safari give the expected result and Opera gives the IE result
Ah, that's crap.
I'm working on almost exactly the same scenario as you are, and I thought I had it. (hadn't entered the IE test fase yet)
Damn it.
I tested the image type input with this page:
http://xhtml.le-developpeur-web.com/input-xhtml.p…
You can see that url is the same with IE6, firefox2 and opera9.
Your problem is probably due to incorrect use of standards.
I tested the imagetype input on the following page to see that IE6, firefox2 and Opera9 generate the same URL.
http://xhtml.le-developpeur-web.com/input-xhtml.p…
Your problem is probably due to incorrect use of standards.
Stef,
Yes, Opera has a long bad history f faking IE behavior.
philippe,
Your page is way too large to spot any differences right away, but if you try the code above, with an HTML 4 or XHTML 1 strict doctype, you will see the same behavior.
And, if you'd like, it would be interesting to know what you regard as incorrect use of standards. Here's the complete test page:
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/DTD/strict.dtd">
<html lang="en">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<title>Testing forms</title>
</head>
<body>
<form action="somewhere.php" method="get">
<div>
<input type="text" name="quantity" value="1">
<input type="image" name="buy" src="images/buy.png" alt="Buy" value="article-57">
</div>
</form>
</body>
</html>
There are some other instance of this happening
– checkbox values are not send if its not checked(same behavior across all browsers)
– The value of the 'submit' type input is send if the user clicks the submit button – but not if he presses enter in another field(IE6 has this issue, I think)
Please, test this page. You will note that if the image isn't find by firefox, the image coordinates don't appears in the URL.
<code>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="fr" lang="fr">
<head>
<title>xhtml : La balise input en xhtml strict (tutorial xhtml) – le-developpeur-web.com</title>
</head>
<body>
<h1>title</h1>
<div>
<form action="" method="get">
<fieldset>
<input type="text" name="quantity" value="1" />
<input type="image" name="monImage" id="image" src="toto1.jpg" />
</fieldset>
</form>
</div>
</body>
</html>
</code>
So, you don't use attribute value with image type input. It's the name of the attribute wich will display.
This is correct behavior according to the spec.
It's a bit unclear though if the value should also be submitted.
As an aside Robert, have you read Seth Godin's article on The Forces of Mediocrity.
The Forces of Mediocrity
As standardistas I think we can all associate with that one lol…
Meanwhile, regarding the forms converstation… I recall hearing something about this a while ago. It works fine without an input type image? Maybe a quick email to Andy Clarke might get the fast answer, its his special area I gather (making ecommerce sites). Just a thought.
I'd also probably use fieldset instead of div and post instead of get but you're probably just showing a simple example so I'll shut up lol… 🙂
Out of curiosity what e-commerce package have you chosen to run with? I've been shopping around for an open source package which can produce good quality markup… so I'm curious what you went with.
sorry about the off topic Seth Godin link but you'll get it once you read his article.
oops… that link was too long and broke the layout. Sorry. Might need fixing. (me creeps away at 7am to walk the dog in silence)
[…] Nyman’s noticing that not all values are posting with a form in Internet Explorer using input […]
Binny,
The behavior with submit button is ok, and desirable, I think. If they're not checked, they don't actually have a value.
Interesting with different values about whether the button was actually clicked or submitted through <kbd>Enter</kbd> being pressed somewhere else in the form.
philippe,
Your image button lacks a <code>value</code> attribute. If you were to add it, e.g. <code>value="Some-value"</code>, you'd see that the value is posted with the form, together with coordinates, no matter if it finds the image or not.
David,
Yes, reading the spec, it's correct (or rather, unclear). It doesn't specify that the value should be sent with regular submit buttons either.
Steven,
Seth is spot on. 🙂
And maybe Andy Clarke should start reading the blogs that matter, so he could've read this and commented then. 😉
<code>fieldset</code> and using POST would be the same for me; it was only used for clarity and actually seeing what's posted in the URL right away.
Regarding e-commerce: this one is custom tailored for this specific customer (meaning: closed source, fairly consultant-dependent 🙂 ), but in general, if you have good advice about open-source packages, I'm all ears.
The image type input does not need to attribute value. The specification pointed by David does not talk because it does not have a purpose.
Firefox doesn't strict complient with W3C spec on the value attribut for the input of the image type.
It's not a problem because Firefox send also coordinate of the image.
You have just need to coordinate value to know if the image type input is present or not.
philippe,
It doesnt need, but that's the whole point here. I want to use it to pass values, form a defined name, to avoid using extra HTML elements.
Safari behaves the same as Firefox, meaning that the only web browser that don't support this is IE (and IE copycats).
This is not a good solution to divert the use of a technology.
If you need to add information in your form, you had better add a hidden fields.
It is better to follow the norms rather than using tips and tricks implemented by some and not by others.
philippe,
Yes, but my hope was to avoid that. And, given that the major rendering engines but IE have implemented it, I'd say the the norm is to support it.
But since they don't, unfortunately it's not an option.
I think that in the context of the Internet, the most important thing is to strictly follow the standards.
Implementing proprietary solutions to solve an issue that is solved by the standard is a danger.
Today many programmers have assimilated amalgam generated by years of non-compliance with the standard by IE.
On your example, we fall in the same issue. It is not because Gecko implements a not standardized mechanism that it is a good practice to use it. Used a non standard will lead to interoperability, accessibility etc. ..
For once that I defends IE 🙂
philippe,
Ha ha, so you take their side! 🙂
In all fairness, though, if one read the specification it doesnt say for other form elements that the value should be posted either.
So, I'd say that the standards in the specification are up for interpretation.
Html4 trying to remain compatible with older standards that were the beginning of the Internet.
The specifications are not perfect. I hope xhtml2 solve this problem.
Indeed we should look today at XForm which will replace the forms that we know which, I am sure, are best specifications.
philippe,
Actually, I'm not even sure what will happen with XHTML 2. I think the de-facto standard will rather be HTML 5.
I did not want to extend me on the subject but since you give me a hand, I take it.
I currently prepare a ticket to support xhtml2 and to denounce the WHATWG because I think that HTML 5 is a danger to future Web.
see:
http://eric.van-der-vlist.com/blog/2008/01/31/htm…
philippe,
Interesting perspective. Thanks for sharing.
This behavior of IE seems to be a remnant from the ancient, obsolete Server-side image map functionality.
I don't see anywhere in the HTML 4.01 Specs that specifically mentions the value attribute of an <input type="image"> element.
Kravvitz,
That might very well be so.
And nope, but it’s not in the specification for some other elements that does send it as well.
The important part of the HTML standard with regard to this issue is 17.13 Form submission, and in particular section 17.13.2 on successful controls.
It is there stated that “Every successful control has its control name paired with its current value as part of the submitted form data set”, and then goes on to explain what constitutes a “successful control” – for example, an unchecked checkbox cannot be “successful”, a reset button can never be “successful”, and so forth.
Unfortunately the image control is not explicitly referred to in this section (although the description of the submission of its coordinates should probably be here, rather than in section 17.4).
As the image control has the action of causing the form to be submitted, it is probably reasonable to instead apply the sentence “If a form contains more than one submit button, only the activated submit button is successful”. As a successful control should have its name-value pair submitted, this would suggest that the description of the submission of the image coordinates should be seen as something to be done in addition to the submission of the control’s value, rather than instead of it.
This interpretation means that Firefox, Safari et. al. are correct, and Internet Explorer is wrong. However, there is sufficient ambiguity in the spec to allow for the argument that IE might be correct – it is at least easy to see that IE behaves as it does in implementing the image control due to an alternative interpretation of the spec.
Personally I feel that, given the lack of clarity in this part of the spec, browser manufacturers should err on the side of submitting more, not less, data derived from successful controls and that the value should be submitted.
@Kravvitz: Section 17.4 of HTML 4.01 clearly specifies that all elements of type input may have a value attribute. It isn't necessary for the spec to explicitly state that image-type inputs may have one, and as they are not explicitly excluded from having such an attribute, it is valid for them to have one.
Nick,
Very interesting, thanks! And I definitely agree with your conclusion.
kind of related:
http://some.server?value=1<=123
this blows up at <= the url becomes
http://some.server?value=1<=123
but only in i.e.
my feeling is i.e. sees '<' as the xml entity <
my question is how do i get around this?
i'm sure the first response is make lt the 1st parameter, so that it becomes ?lt. but what if that's not under my control???
any thoughts are appreciated.
Hi Joe,
The best solution is that you should take an other name for your parameter.
Joe, without testing I ask: How are you encoding your ampersands in urls? You can’t just write an ampersand directly – even in a url you must use the html entity.
If this isn’t the cause then just ignore me… My big tip: Validate the document (and use verbose validation if you can handle it)… If the problem is what I think it is, this is one of the things the validator can explain better than I.
[…] IE 6 not sending post value of Input type Image February 3, 2009 — rick schott The same issue was reported here and here. […]