This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
As was described by several users - seeing their webapps break in Firefox4 opposed to a working Webkit/Firefox3; https://bugzilla.mozilla.org/show_bug.cgi?id=583211#c1 I would like to propose an alternative algorithm for input type image; Currently; 4.10.22.4 Constructing the form data set 3.3; 1..4 3.3.5. Append an entry to the form data set with the name namex, the value x, and the type type. 3.3.6. Append an entry to the form data set with the name namey and the value y, and the type type. 3.3.7. Skip the remaining substeps for this element: if there are any more elements in controls, return to the top of the loop step, otherwise, jump to the end step below. I would like to introduce step 3.3.6a. analogue to 3.9; Append an entry to the form data set with name as the name, the value of the field element as the value, and type as the type.
I perfectly agree with this suggestion. Current implementation is illogic (why every input element sends its value but image input elements do not?) and breaks existing internet/intranet websites.
How can it break internet sites, when the majority of deployed browsers don't send this name/value pair? I can see how it might break browser-specific intranet sites that rely on the other behavior in specific browsers. But I'm not sure we shoud worry any more about those than we worry about IE6-only intranet sites.
(In reply to comment #2) > How can it break internet sites, when the majority of deployed browsers don't > send this name/value pair? > > I can see how it might break browser-specific intranet sites that rely on the > other behavior in specific browsers. But I'm not sure we shoud worry any more > about those than we worry about IE6-only intranet sites. Since before there was no explicit form submission algorithm every browser implemented it as it liked and so did intranet developers (who of course developed their websites accordingly to their company business rules [including which browser to use]). So, if this submission algorithm affects only HTML5 websites (and it does not) then there would be no problem at all, but since it affects _every_ HTML implementation it does retroactively break existing sites. I don't see any logic into the current implementation (as i said, why image input elements do not send their value and other input elements do? is there a logic reason that we don't know?) so this seems more like an error/bad-choice in the algorithm than something that exists for a reason. Also, previous HTML 4 documentation (http://www.w3.org/TR/html401/interact/forms.html#h-17.4) says nothing at all (or at least i can't find it) about the fact that the name-value pair should not be sent and although HTML 4 specs are outdated this implementation adds a (illogic) rule that removes the name-value pair even from pre-HTML5 implementations. So the question is: is there a logic behind removing the name-value pair? Is there a reason? If not then why shouldn't this be considered a retroactive rule that breaks existing sites?
> and so did intranet developers I explicitly said that I understand how intranet issues can arise. You claimed there are broken _internet_ sites. I'd like to understand your basis for this claim. > I don't see any logic into the current implementation It's what IE does and what matches the HTML4 spec most closely.
(In reply to comment #4) > > and so did intranet developers > > I explicitly said that I understand how intranet issues can arise. You claimed > there are broken _internet_ sites. I'd like to understand your basis for this > claim. The forget about the internet sites and lets think about intranet sites and in general about the logic in this algorithm. > > I don't see any logic into the current implementation > > It's what IE does and what matches the HTML4 spec most closely. What is the logic about "It's what IE does"? Can you tell me where in the HTML4 spec it says that the name-value pair should not be sent? How is IE implementation better than, say, Firefox 3.6 or Google Chrome? Also, what if the user does not use the mouse? Wouldn't it be more logic (especially in the keyboard-only case) to also send the name-value pair (as for other input elements) since most sites (intranet and not) use the image input element not as an "imagemap" (where X,Y coordinates are necessary) but just as a graphical representation of a button (where X,Y coordinates just do not matter at all)? IMO the current implementation is just illogic. There is no reason i can see why the image input element should behave differently than other input elements. Of course i can be wrong and there is a logic reason behind it beside "IE works like this"... but if there is i would like to know it.
> and lets think about intranet sites See comment 2. > What is the logic about "It's what IE does"? The logic is simple. As of when the spec was being written IE and Opera sent just .x and .y; WebKit and Gecko sent those and the name/value. To converge on a behavior here, either IE and Opera would have to change or WebKit and Gecko would have to change. So the editor had to pick one or the other behavior, with a 50-50 split. He picked one. Now please go and read the mailing list archives, where this is all discussed at length, instead of asking me to repeat all the arguments, ok?
(In reply to comment #6) > > and lets think about intranet sites > > See comment 2. > > > What is the logic about "It's what IE does"? > > The logic is simple. As of when the spec was being written IE and Opera sent > just .x and .y; WebKit and Gecko sent those and the name/value. To converge on > a behavior here, either IE and Opera would have to change or WebKit and Gecko > would have to change. > > So the editor had to pick one or the other behavior, with a 50-50 split. He > picked one. > > Now please go and read the mailing list archives, where this is all discussed > at length, instead of asking me to repeat all the arguments, ok? So the editor picked the only behavior that had a chance to break existing sites. I see the logic. Thank you for your clarification. Also, where is this mailing list?
Both behaviors can break existing intranet sites. Neither one should break existing internet sites. http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/ and http://lists.w3.org/Archives/Public/public-html/ are the two places where this sort of thing is discussed.
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: <http://dev.w3.org/html5/decision-policy/decision-policy.html>. Status: Rejected Change Description: no spec change Rationale: Three browsers have converged now. Lets keep this as is.
The only reason Firefox seems to have switched behavior was because IE and Opera didn't have consistent behavior. Given your email address, we now know where this reasoning came from, but not why HTML5 is crippled.
Since this still is 'consistent' in the webkit alternative and was in the previous Firefox series. Requesting the HTML5 standard to be extended so every input field communicates at least name and value.
mass-move component to LC1
Is there a testcase demonstrating the various behaviours here? Is there any documentation on which sites this behaviour breaks? Which browsers had which behaviour? I'd like to study this further. Note that HTML4 required the same thing (albeit in its usual vague manner). If browsers didn't do what the spec says here, they weren't doing what HTML4 requested. If sites depend on such broken behaviour, that's really their fault for not following the specs either. But if they're major sites or if many browsers do this the other way, I'm certainly not opposed to changing the spec.
(In reply to comment #13) > Is there a testcase demonstrating the various behaviours here? Is there any > documentation on which sites this behaviour breaks? Which browsers had which > behaviour? I'd like to study this further. I can only comment on the fact that after our CMS broken on 'mandatory' Firefox upgrade, I went searching in the bugtracker of Mozilla and found a not of noise on the why this change was pushed trough. Historically I know that the behavior this change request would like to achieve was supported on Firefox < 4. And is still supported in Safari and Chrome. I am certain it never worked in Internet Explorer. I have no data on Opera. The rationale for us using the image submit (historically) was presenting the user with several graphical panes that could be choosen from, renderings of a screen. Analogue to a submit button having text. Now you could argue: "but why don't you use CSS to set a background image on a submit button". This was indeed the solution to get crossbrowser support. But reading the documentation on W3Schools: "image Defines an image as a submit button" My point being: functionality wise nothing is lost by moving to type=submit/background-image. But are we really going to define a standard that explicitly makes one exception on name/value passing? I'm not puting the more radical: "why not remove the 'img' tag, because you could use a div tag with background-image", argument here. Because it is clearly a no brainer the functionality is already in place, only an explicit exception is made.
Do you have any links to test cases showing what you describe?
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Did Not Understand Request Change Description: no spec change Rationale: Need test cases to understand request.
Created attachment 1028 [details] Ideal and Emulated behavior. As requested. http://stefan.konink.de/contrib/html/inputtypeimage.html <html> <head><title>Test of image=type</title></head> <body> <form> Original:<br /> <input type="image" src="/i/oog.jpg" name="postthis" value="POST ME" /><br /> Emulated:<br /> <input type="submit" value="POST ME" name="postthis" style="border: 0; background-image: url('http://stefan.konink.de/i/oog.jpg'); background-repeat: no-repeat; width: 678px; height: 509px; font-size: 0;" /> </form> </body> </html>
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Rejected Change Description: no spec change Rationale: Thank you, that was perfect. Here's a live DOM viewer version of this test for those following along at home: http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1267 Looks like Gecko, IE, Opera, and the spec all agree. WebKit seems to be the lone dissenter; WebKit also submits the value attribute's contents as name=value. I don't really see a good use case. Compatibility doesn't seem like a compelling reason here since no major sites have been brought to light that suffer from this, and only one report has come up at all (for an Intranet site). The authoring issue is easily resolved, either on the HTML side or the server side, so there's not a compelling argument to be made for authoring convenience here either. In conclusion, I think the spec is fine as is here.
[quote] Looks like Gecko, IE, Opera, and the spec all agree. WebKit seems to be the lone dissenter; [/quote] Incorrect. Gecko migrated to the 'work in progress' spec, before, Firefox was also working in the described way. I posted this bug because of the gazillion bug reports on the Mozilla bugtracker system, I don't see this as an incident of one intraset website. Especially not considering this is a W3Schools example. [quote] I don't really see a good use case. [/quote] Then just answer the trivial question: why is any input type button posting a name and a value, except for type=image. It is far from a logical decision, which in this entire thread I am asking for. Why remove the feature and not complement it like happens for every other input-tag?
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]
> Especially not considering this is a W3Schools example. Just to butt in on that... The vast majority of W3Schools examples are wrong, in my experience. Since the people maintaining it don't fix them when you point it out to them, they're likely to stay wrong. I wouldn't base anything on what W3Schools says (except maybe treating it as a list of things to not do).
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Rejected Change Description: no spec change Rationale: (In reply to comment #20) > I agree with Stefan. The current implementation is illogical. HTML is illogical all over the place. > It breaks the > expected behavior without a good reason to do so (or at least none that i can > see). The element represents a coordinate. The expected behaviour, IMHO, is to send a coordinate. Sending a coordinate and a value is unexpected. > Every input element sends the name-value pair, beside this one. Is there a > logical reason to do so? No, not every input element does this. In fact, the behaviour of input elements is highly inconsistent. type=file includes a file and a filename, checkbox and radio buttons are included or not rather than having their value change, and their value is defaulted to "on" rather than the empty string, <select> elements can have multiple values for one name, the whole thing is completely inconsistent. > 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. Sure, and that works fine, regardless of what we do here. > but IMO, by doing so, you are leaving a logical inconsistency in your > specs with an unmotivated exception It's not unmotivated. I've explained the motivations. > 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. I don't see how it's unclear. The value attribute is not conforming... how could a value be included? (In reply to comment #19) > [quote] > Looks like Gecko, IE, Opera, and the spec all agree. WebKit seems to be the > lone dissenter; > [/quote] > Incorrect. Gecko migrated to the 'work in progress' spec, before, Firefox was > also working in the described way. It might have been incorrect in the past, but it's not incorrect now, which is what I care about. > I posted this bug because of the gazillion > bug reports on the Mozilla bugtracker system, I don't see this as an incident > of one intraset website. Please list the pages affected by this problem. If it affects big sites, or many small sites, then that is data that will affect the decision. > Especially not considering this is a W3Schools example. http://w3fools.com/ > Then just answer the trivial question: why is any input type button posting a > name and a value, except for type=image. The premise of the question is false; other types do things other than just post name=value too. But even if that were not true, the answer is "because a coordinate is two numbers, so we return two numbers". Also, "because that's what most browsers do". > It is far from a logical decision, Logic really doesn't factor into HTML's design. There's a reason the WHATWG tag line is "Please leave your sense of logic at the door". > which in this entire thread I am asking for. Why remove the feature and not > complement it like happens for every other input-tag? We didn't remove it. It has never existed except in two rendering engines (now one) which were implementing a non-standard behaviour. Any page depending on this, for example, would never have worked in IE.