[Bug 12687] 4.10.22.4 Constructing the form data set - for input type image

https://www.w3.org/Bugs/Public/show_bug.cgi?id=12687

--- Comment #20 from Luca Tomat <luca.tomat@gmail.com> 2011-12-03 01:27:07 UTC ---
I agree with Stefan. The current implementation is illogical. It breaks the
expected behavior without a good reason to do so (or at least none that i can
see).

Every input element sends the name-value pair, beside this one. Is there a
logical reason to do so?

Input elements with type=image are not only used as imagemaps, they can also be
used as simple graphical buttons where the X and Y coords are just irrelevant
and what matters is only the name-value pair to say "yes, this button has been
clicked"... more so because the user might not use a pointing device to click
on it making the coords absolutely useless. There are other ways to accomplish
the same effect so it is not a big deal, not anymore anyways since most
internet/intranet websites are probably updated by now, but as i said what you
expect is to receive the name-value pair, since every other input element sends
it.

You can even close this bug and leave the things as they are, i don't even care
anymore, but IMO, by doing so, you are leaving a logical inconsistency in your
specs with an unmotivated exception to the general rule "every input element
sends the name-value pair" which you should at least make it clear in the HTML
specification since, as i said, this is not what developers would expect.

Also, from the explanation here:
http://www.w3.org/TR/html4/interact/forms.html#h-17.4
it is not clear that the name-value pair is *not* sent. All what it says is
that the submitted data _includes_ name.x and name.y but this by no means tells
the reader that the name-value pair is not sent.
[Yes, it is a link to the HTML4 specs, but this inconsistency is practically
retroactive affecting HTML4 websites too]

-- 
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Saturday, 3 December 2011 01:27:09 UTC