What does the HTML spec say about using enter key to submit a form?
I've read http://www.w3.org/TR/html4/interact/forms.html but nothing there about submitting a form using the enter key.
Is it even defined somewhere or is it just the way most browsers have implemented it on their own and it became the way to do it?
I'm curious because I just asked a question regarding Webkit not submitting my form if the submit button is hidden (display: none).
Trying to 'submit' my form when hitting enter fails
So is there somewhere in the official docs a reference to the behavior of the enter key in a form?
The HTML standard is device-agnostic; HTML user agents run on a variety of platforms, many of which (think search engine, voice reader, webscraper) do not have a keyboard in the first place. Therefore, the standard does not say how a user can toggle the form submission. Listing all possible ways to submit a form is impossible, since many devices and user interaction mechanisms are not invited yet - iOS 6 may allow you to submit a form by saying "Submit Form!".
The Webkit behavior you're seeing is up to the discretion of Webkit and likely unintentional. The standard does not say anything about a submit button being necessary in the submission process.
It's not part of the spec. It's something that the browser makers implement at their discretion.
I know this question is old but I just had the same issue with webkit browsers. I found if you use visibility: hidden in lieu of display: none the enter button will submit the form. I know this adds a few more styling challenges but it essentially accomplishes the task. As far as the standard goes, it's been over a year and I failed to find anything more informative than phihag's answer.
The spec says that all forms are required to have an action attribute. If you have one of these, the enter key will work. I've got forms with no submit button at all, and the enter key is functional.
You can attach javascript to the submit event, which could prevent the browser from navigating to the action uri.
But whatever you do, you are required to have an action uri, and it should be functional.
Related
I want to "prevent browsers from prefilling form inputs when hitting the "back" button". Indeed, I want the initial values to be filled in (added via jsp), not the browser's (cached) values.
Solution 1: I found out that this can be done by disabling the browser caching for the current page. This seems a rather extreme solution considering that I "only" want to disable this prefill feature for a "form" (hence disable caching for the form only, not the whole page).
Solution 2: Then, the obvious next solution is to use javascript: that is, store the initial value in a data-* attribute, then, on page load, replace the input value by the initial value if they differ.
Both solutions seem rather unperfect (these are rather work arounds) I turn to you guys hoping to hear of a better one.
Resources:
How does SO's form remember previous input values?
Disable Firefox's Auto-fill
Pressing back prefills inputs with value from right before submit
HTML form values and 'Back' button
The first thing that comes to my mind is to use a <input type="reset"> button. These aren't seen often nowadays because the user rarely actually wants to reset the form, but here it might just be what you need.
You could also do it in javascript on page load with form.reset(); instead of providing a button for the user.
https://developer.mozilla.org/en-US/docs/Web/API/HTMLFormElement.reset
This is similar to your solution 2 and thus still a workaround of the browser behavior, but it is a(n old) part of standard forms and I think it'll do the trick with very little additional code (no need for data-* attributes), so wanted to throw it out there.
I have a web application for tagging data and viewing data by tag, so my UI is a list of checkboxes for each tag, a list of checkboxes for each data item, a "Tag" button, which adds the checked tags to the checked data, and a "Filter" button, which ignores the checked data and just displays only the data items with the given tag.
My problem is that the former operation (tagging data) is "obviously" a POST operation, whereas the latter operation (viewing data according to a tag) is "obviously" a GET operation. But the method attribute is attached to the form, not the submit button, so I have to choose one or other for both buttons.
I don't want to make two forms, since as far as I can tell this would force me to duplicate the entire tag list. Is there any way I can choose my method based on the choice of submit button?
A JavaScript solution is permissible, but one without would be preferred.
(I am going to post an answer to this question, but I don't particularly like it, so I would welcome alternatives).
In principle, you could use the formmethod attribute in a submit button, as per HTML5. However, it is not recognized by IE, even in IE 9. The existence of the feature in HTML5 indirectly proves that previous versions of HTML lack a feature for this.
On the other hand, the POST method can be used even for simple viewing that does not cause any changes in the outside world, and in many situations it has to be used for technical reasons (e.g., too much data). So I think the method issue is not very relevant; just use POST.
I would honestly go with a javascript solution, in the onsubmit of the form fire a method which a) checks the submit button that was pressed and b) based on this changes the method of the form.
One possible solution would be to use POST, and then have the server give a 303 See Other header to change it into a GET request. This involves making two requests to serve the purpose of one, which is unfortunate, but at least means that the URL will change so people can link to a specific tag selection.
I agree with javascript solution, proposed by Jon Taylor, the problem is not if your form's method is GET or POST, but how do you filter/validate/sanitize user input. If your concern is related to the fact, that the user can manipulate the form's method, then you should implement solution to that matter on server side.
I'm building an HTML multiple-choice quiz and am aware of a technique which would let me use multiple submit buttons - one for each answer to an individual question. I could then process the form in PHP using submit button values and determine which answer the user has selected. The reason for using submit buttons is so that they can be styled appropriately.
However, I'm wondering if this is bad practice from an accessibility perspective? Would it be better to use an individual form for each answer to a question? There are plenty of questions on here about how to use multiple submit buttons but they don't seem to address this point.
It's absolutely fine, and in a lot of cases can improve the usability of a form. Be careful however, as there are a couple of gotchas:
If the enter key is used to submit the form, the submit behaviour is undefined. HTML5 does define this behaviour, and it specifies what most browsers already do in this situation: The first submit button in the form should have its name/value sent as part of the submission.
However IE<=8 don't send the name/value pair for any submit button when the enter key is used to submit the form.
So, you have to be aware that there needs to be a "default" action for the form, and that has to be the first submit element present.
You can't use this technique to submit to a different action based on which button was pressed. Javascript can theoretically solve this, but you shouldn't do that (a good mantra is, don't use Javascript to solve a non-Javascript problem)
What will you do if the form is submitted using the Enter key on the keyboard, and none of the submit buttons is in the data you receive server-side?
I have a form with multiple submit buttons, each of which is relevant to how the user wants the data saved and/or loaded.
The problem is (or was) that if a user pressed enter on the last (or any other) input within the form, the submit button that seemed to be called was the "load saved formed" which is at the top of the form. All attempts to user javascript to have the return button default to the "save form" seemed useless, almost as if the browser was too busy already submitting the form to have any js interfere.
Finally, in FireFox 3.5, I actually had the server-side script echo out what it received for the post variable and discovered that none of the submit button values were being passed back to the server. As it turns out, I have hooks in the script for when the user hits "Save" or "Save and Print", etc, but if the user uses the "load page" it simply updates a variable and continues loading the page normally with that variable in context.
So with no submit button value at all, it did the same thing, it simply loaded the page.
So, on to the big question:
Is this typical browser behavior? Maybe even reliable browser behavior? Will hitting enter always submit the form as though no submit button was pressed at all, or do some browsers like to pick a button to use as the default when the user presses enter?
If it is typical behavior, what is the suggested course of action? I was going to have the script save anything no matter what, so long as there was data in the form, but then I realized that this was even more dangerous, because if the user loads one saved form, changes there mind, and changes the form dates and hits "Load Form", then it will save the form data from the pervious form for the new dates they have requested.
I considered setting it up so that changing the load form inputs (selects with dates and other particulars) would clear the form so that the server still recieved an empty form and thus would not overwrite any previous data, but this is risky as well, as many users will certainly notice and think that their data has been lost, etc, and there is always the slight chance that the user will be almost done with the form, go up to the top and fiddle with the form-load selects just to confirm they chose the right what nots and then be forced to start from scratch.
I should just have two forms, one for loading, one for the data, but the problem with that is that all of the data in the load part of the form does get used by the main form. I could write more js to combine the two on submit, or hide the data in the second form, but all of that seems clunky.
Essentially, I need a setup such that the top part of the form is independent of the main form, but not vice versa. Submitting the upper form does not submit the lower, but submitting the lower does submit the higher.
Okay,I've gone on long enough. Basically I'm wondering if a solution already exists or if anyone else has run into this and found a clever fix. I thought simply having the form save whenever the form wasn't empty was pretty clever, until it occurred to me that when the user goes to the page, it auto-loads the most applicable form given the date, and thus changing the load variables will almost always caused trouble.
Having read the possible duplicate that Artelius was good enough to draw my attention to, I'm still unclear on the consistency across browsers regarding the Enter button as submit.
It seems that almost everyone in that question assumed that hitting enter presses the first available submit, which was also my assumption until a friend suggested I hide (via CSS) another submit button at the top of the form with whatever I wanted enter to achieve. It was when this got me the same results that I finally viewed what was being passed to the server (ie nothing in terms of a submit value). So that means either
a) the "enter as no submit button just submit" is new behavior for some or all browsers,
b) the "enter as just submit" vs "enter as first submit button" is just browser choice, no trends, just typical cross-browser unreliability, or
c) Everyone just keeps assuming that the "enter as first submit button" is the case because most of us only code if (situation1) else (assume not situation1) and none of us are really sure what the browser is doing.
I highly doubt it's that last one, but then again, I also highly doubt most of us know which browsers do which. I'd sure like it if there was a straight answer I could pass along.
Oh, and finally: While I know it would be far simpler to use buttons, and I am taking that under serious consideration, I would also like to consider other options, since really the only need for less submit buttons I have is for when users hit enter instead of one of the buttons.
Actually, let me get carried away one more second:
The only thing I really need to know is whether or not they hit enter FROM one of the text inputs. If I could pass that along to the server, I'd know if I should save or reload the form. But the problem is (or at least what I've had troubles with) is that when the user hits enter in an input, it seems like there isn't any more playtime with js to capture anything, and in some cases, it seems like the browser is triggering the onclick for whichever submit button and thus not really allowing me to know the real event that triggered that. I'll play around more with jquery, but has this behavior been observeed by anyone else?
My best advise would be to only have on submit button, and let that submit what ever is the most common usage of the form. Let the rest of the buttons just be normal buttons, which you can hook click events onto.
Just make sure you make it very clear which button will be "pressed" when the user hits enter. Let the submit button be the biggest one. If you have 3 buttons that are used equally as much, I would just drop having a submit button at all...
edit: I'm pretty sure most browsers will post all the data inside a form. If you want to do some checking on the data before posting you could add a listener for onsubmit
<form onsubmit="checkData(this);" ... >
Passing in this will let you check which form is actually being submitted:
function checkData(form) {
var formName = form.id;
//check all the data based on which form is being submitted
}
The HTML5 spec specifies synthetic click activation steps for implicit form submission:
A form element’s default button is the first Submit Button in tree order whose form owner is that form element.
If the user agent supports letting the user submit a form implicitly (for example, on some platforms hitting the "enter" key while a text field is focused implicitly submits the form), then doing so for a form whose default button has a defined activation behavior must cause the user agent to run synthetic click activation steps on that default button.
I've got a form like this:
<html>
<body>
<form onSubmit="alert('Just got submitted');">
<p>
Hello: <input class="field" type="text"/><br/>
Goodbye: <input class="field" type="text"/><br/>
</p>
</form>
</body>
</html>
which in one browser submits happily on user pressing enter from one of the fields, and in another browser, doesn't. Oddly, if I remove the second field, it works in both.
My question is really - is it okay to have a form with no explicit submit element? I really like this behaviour.
Having no explicit submit is poor user experience. Your typical end user has, over the past decade, learned a set of principles for website form interaction. Namely, you can tab between fields, you can select lots of checkboxes, and you have a click a button to actually submit your data.
I've tried developing forms in the past that automatically update with JavaScript, and I got countless complaints from users. They wanted a button or they didn't believe it was working. So in that particular case, I kept the form working as it originally had, but added a submit button that really didn't do anything. They were happy.
These days I just build out my forms with normal submit buttons. Not only do users expect it, but it allows for much cleaner progressive enhancement between non-JS enabled browsers.
It's certainly more than possible to have a form with no submit element, especially if you use JavaScript events to submit the form. I highly suggest you use the onkeypress event to detect the "enter" key being pressed rather than depending on the browser to just accept the "enter" key if you make a form with no submits, to make it cross-browser compatible.
However, I think it's bad form to leave out a submit button of some sort. (It doesn't necessarily have to be an input of type "submit", could be "button" or an image you click.) It's just a standard to have forms that people fill out submitt via a button, and you're taking that away, which could confuse many users who are used to a button. It definitely violates the principles of Don't Make Me Think by presenting an alternate form to the norm.
It's not a good idea. You point out the reason yourself - it doesn't work in all browsers. Also, it's not what people expect, so it may confuse people.
It depends on what you mean with "ok".
If you mean valid (x)html, well it's no problem at all, but on the user side, it's a usability issue. But it also depends on the target audience of your website. If its for tech savvy people, then it's ok.
You could create an input button like this:
<input type="button" onclick("doSomething()") />
The doSomething() would be a function in Javascript that would send your form data to a server-side script. This way you wouldn't have a submit behavior.
Submitting a form on 'Enter' with jQuery?
Also, I'd leave the button in the form, but hide it with javascript ($('#submit').hide()). It means that if the user has disabled script or f.ex. uses some other device, he'll see the default way to submit the form.
If you want to have two buttons which generate two different behavior when submit. what you can so is something like that:
or you can put the form submit inside function1() or function2()