The best solution is that you should take an other name for your parameter.

http://some.server?value=1&lt=123

this blows up at &lt= the URL becomes

http://some.server?value=1<=123

but only in i.e.
my feeling is i.e. sees ‘&lt’ 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.

Very interesting, thanks! And I definitely agree with your conclusion.

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.

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.

I don’t see anywhere in the HTML 4.01 Specs that specifically mentions the value attribute of an <input type=”image”> element.

Interesting perspective. Thanks for sharing.

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/html-5-turns-documents-into-applications/

I hope xhtml2 solve this problem

Actually, I’m not even sure what will happen with XHTML 2. I think the de-facto standard will rather be HTML 5.

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.

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.

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

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.

If you need to add information in your form, you had better add a hidden fields.

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

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.

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 Enter being pressed somewhere else in the form.

philippe,

Your image button lacks a value attribute. If you were to add it, e.g. value="Some-value", 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.

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