1, the type attribute of input in HTML5 already has tel, number, email, also need to write the regular to verify it?
2, the type attribute of input in HTML5 total is 13 new, I summed up the 13, respectively, the type of these attributes: color (definition Color picker), date (define Date field), DateTime (Define Date field), Datetime-local (defines the date field), month (which defines the date field), Week (the week in which the Date field is defined), time (hours, minutes, seconds of the date field), email (the text field that defines the e-mail address), number (which defines the The spinner control's numeric field), range (which defines the numeric field with the slider control), search (the text field defined for the search), tel (the text field defined for the phone number), and the URL (the text field defined for the URL).
Usually in the use of the site when the very few, we usually write the time directly with these, or need to write their own regular, or use other tags to the simulation instead of it?
3, ask for help you to HTML5 new view of these 13 type attributes?
Reply content:
1, the type attribute of input in HTML5 already has tel, number, email, also need to write the regular to verify it?
2, the type attribute of input in HTML5 total is 13 new, I summed up the 13, respectively, the type of these attributes: color (definition Color picker), date (define Date field), DateTime (Define Date field), Datetime-local (defines the date field), month (which defines the date field), Week (the week in which the Date field is defined), time (hours, minutes, seconds of the date field), email (the text field that defines the e-mail address), number (which defines the The spinner control's numeric field), range (which defines the numeric field with the slider control), search (the text field defined for the search), tel (the text field defined for the phone number), and the URL (the text field defined for the URL).
Usually in the use of the site when the very few, we usually write the time directly with these, or need to write their own regular, or use other tags to the simulation instead of it?
3, ask for help you to HTML5 new view of these 13 type attributes?
Regardless of the front end verification, the backend must be verified.
These types just make it easier for browsers to display different controls, and different keyboards are called on the phone, but they are essentially strings that are not guaranteed to be properly formatted.
Front-end verification is just a better user experience, without jumping pages like back-end verification (Ajax doesn't jump, but still transferring data), but it doesn't guarantee the validity of the data.
It needs to be clear about this.
type
does not serve as a basis for verification,
The Type field simply provides the selection format for the input,
In more cases it should be said that the new type is designed to match the presence of mobile web apps
For example, when you type=tel
open a page on your phone, you'll get a phone keypad (not a numeric keypad, not the same, and the phone keypad also includes *
and #
).
When type=email
, there will be a band @
and .com
symbol of the full keyboard (each of the system implementation seems to be different)
That's why we have to pattern
exist,
When the post is submitted, the browser matches the input to the pattern attribute to determine whether the input is valid.
Of course, the validity of the backend validation data is beyond the scope of this issue.
PS just tried again, chrome under when or when type=email
type=url
, triggered the submission, even if not pattern
also will check the input content and then prompt, but type=tel
no, Safari is not all the content check, This is the browser manufacturers each implementation of the differences, in order to maintain the consistency of browser behavior, should be added pattern
attributes
As a web developer, it is not credible to consider the data that the front-end user loses, and it is possible for the backend to have malicious code to verify
Front and back verification is not optional, but necessary! Moreover, some of the new properties have compatibility issues with individual mobile browsers!
Do not consider back-end verification, just say front-end verification. the place to validate is still required to verify
For example HTML5 type = Email,number and other browsers for you to verify, but Tel has no, do not know whether you are mobile phone number or landline, Tel entered the letter did not do verification.
In general, make up for the missing verification according to the specific requirements.
@funkyLover said very well.
As for your first two questions, I think it depends on your development needs: what are the strict requirements for the format of input values and browser compatibility?
If the data is ultimately used only to show people (such as some personal information on a regular site) and does not have to be compatible with earlier browsers, then these type attributes are sufficient for the authentication mechanism.
Conversely, if the data will be used by the machine (such as Automatic e-mail) or critical information (such as the contact telephone in the intermediary site), or to be compatible with the early browser (does not support HTML5), then you need to write the front-end verification function code.