Deep analysis of form form in HTML

Cause

Recently, you have seen these issues in groups such as the following:

How do I press the ENTER key on the keyboard to submit the form?
How does the mobile end focus when the keyboard becomes a number key?
How does the mobile end bind the "submit Button" event in the lower-right corner of the keyboard?
The mobile end of the keyboard in the lower right corner of the "submit" if replaced by "search"?
Share some of my suggestions for using the form for these issues.

Before optimization

<ul>
<li>
<span> User name:</span>
<input type= "text" name= "username" >
</li>
<li>
<span> Password:</span>
<input type= "password" name= "password" >
</li>
<li>
<span> Search terms:</span>
<input type= "text" name= "key" >
</li>
<li>
<span> Mobile phone number:</span>
<input type= "Text" name= "Tel" >
</li>
<li>
<span> Age:</span>
<input type= "text" name= "age" >
</li>
<li>
<span> Self Introduction:</span>
<textarea name= "Content" ></textarea>
</li>
<li style= "padding-left:70px" >
<input type= "button" value= "Save" id= "J-save" >
</li>
</ul>

<script>
$ ("#J-save"). On ("click", Function () {
Verifying information

Asynchronous or synchronous commit
Alert ("In-store");
});
</script>

The above code is the structure of common form elements, usually binding the click event of the Submit button, and then processing the information that validates the user input, and then asynchronously or somehow jumps with Ajax.

Also some FE will set a form tag, but it is also a bound click event.

Optimization point
The optimization points for the above form elements are as follows:

Always use form labels
As long as the form element is always wrapping the form tag in the element's outer layer, let's say that we all work together to semantic.

Always bind submit Events
Bind the Click event to the "submit" button separately, bind the entire form to submit the event, so that the text box in the entire form gets the VIP treatment for the Enter submission, and the lower-right corner of the keyboard is "go" when the text box is focused in the mobile end.

Plus the validation + focus on the element values in the form, you can achieve the "input-> carriage return-> error-> input-> carriage return-> submit" coherent experience.

This will solve the above problem 1, question 3

Placeholder occupies a position

Reasonable use of placeholder placeholder, but consider compatibility. Compatibility scenario:

Use value simulation to see if value is the default placeholder value when submitting, compare pits
Using the span label to position the display, you need to consider the trigger when setting the element value directly
MaxLength
If you know the ideal input length of an element, you might want to set the maximum length attribute of the element, and the compatibility is good. To a certain extent to avoid the user's error input, thereby enhancing the user experience.

Label
The description text for the form element should be wrapped with a label label, and use the For property to point to the form element to achieve the effect that the click Description text can focus on the text box, such as:

<li>
<label for= "J-username" > Username:</label>
<input type= "text" name= "username" id= "J-username" >
</li>
State at the time of focus
When the text box is focused, the theory should let the user perceive it, not motionless.

Position of the page when focusing
When focusing, consider the best viewable range for the page to scroll to the focus element.

You also need to consider when focusing on the mobile end of the page old run deviation ...

Asynchronous Submit status of form
When a form asynchronously commits the data that needs to be sent backwards, it may experience the status of commit, commit error, commit success, and take into account the issue of resubmit (repeated submissions) in the submission.

For example, to set the Submit button's disabled = True at commit and make it grayed out, show "Submit ..." Is it more friendly? The question of holding hands I will not say ...

Further extension
Due to slow user network, the user submitted the form without loading JS
Back-end native support-back end even if pure form commit can receive normally
Default Block-the form label defaults to block onsubmit= "return false", which is processed when JS initializes
AutoComplete-to determine whether to use self-service completion based on the business scenario, you can add it throughout the form form, or you can add it to the INPUT element
Fixed expiration of moving end text focusing
Reset button in form