We can’t change history, but we can change the future.
Be nice to each other.
@robertnyman

Not all values posted with a form in IE

Published on Thursday, March 6, 2008

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:

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… 🙂

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.

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.

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

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.

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.