The return key in comments

Question

I have noticed recently that when composing comments, pressing the return key submits the comment as is. This behaviour differs from that when composing replies. I am using Firefox. As I frequently press return, I find that when writing comments I have to keep opening up the inadvertently submitted comment for editing. I don't recall this happening more than a few days ago. So, at least one user finds this "feature" annoying and would like this bug squashed. Is it possible to ensure that comments can only be submitted by pressing the "add comment" button?

Answer 1

Let me relate a related thing that happened to me.

Before Microsoft's Internet Explorer there was Netscape, and I used Netscape for accessing web-based email. You clicked the mouse on a submit button to send the email. While composing the email I would edit the text until it was ready by deleting bits of text, rewriting bits and splitting long sections into paragraphs by using the enter key, but to do all this I moved the cursor around the textarea by clicking the mouse on the part I wanted to edit.

Then came Internet Explorer and I began to use IE instead of Netscape, but when I was editing an email to split a long section into paragraphs by inserting a newline I would click the mouse at the beginning of the line and then press Enter (and you can guess what happened). I thought I had clicked the mouse at the beginning of the line but I had actually clicked a few pixels too far to the left, so when I pressed Enter the active item was not the textarea but the webpage so pressing Enter submitted the email and sent a half-baked email. At the time I didn't realise what had happened, because I was familiar with Netscape which didn't have this "pressing Enter to submit" behaviour, so I started again and the same thing happened, and then again but this time I was deleting a character but pressing delete outside of the textarea activated the browsers back button, although I didn't realise it at the time. All in all I don't know how many half-baked emails I sent in succession to that person, but I never heard from them again so I reckon they were not impressed.

To sum up, I think it is absolutely shocking user-interface design to have "pressing Enter to submit" behaviour when textareas are involved where the Enter key is used for creating new lines and paragraphs. 4 paragraphs in this long spiel.

Answer 2

Interestingly, as of June 22 Enter no longer adds comments on the main site for Japanese Language & Usage. The change was in response to problems it caused for users of Input Method Editors, a point that was raised on meta.SO last September.

Answer 3

It is actually a new feature. I don't think there's any plan to make the old behavior accessible.

---

Edit: there is an easily installable Greasemonkey script to change this behavior, that works with Firefox and Chrome, here. Instructions at the following link with screenshots:

http://stackapps.com/questions/2061/disable-enter-for-submitting-comments

Answer 4

Just for your information, this is the background on how the internet works.

On the Internet, there are two basic forms of text input, the <textarea> element (which is specifically designed for long multiline input) and the <input> element. (which also handles radio-buttons etc.)

if we look at the HTML 2.0 specificaction dated 1995-09-22, more specifically the Form Submission section, you will notice the following passage:

When there is only one single-line text input field in a form, the user agent should accept Enter in that field as a request to submit the form.

^{(this is a reference to the <input> element)}

When Microsoft made Internet Explorer 4, they implemented this to the letter of the law, resulting in different behavior, based on the occurance of one or more <input> elements in the form.

Now, while the newer version of this specification do not have any such passage, nor any other equivalent text; over the years, all browser makers have standardized on one common behaviour, enabling the highest accessibility for all users, including those who can not use a mouse, and are required to use keyboard navigation.

This includes (but is not limited to):

• tabbing through links and fields.
• pressing the enter key to enter a link destination, or to submit your form input.
• pressing space to (un)select an option on radio-buttons and checklists.