Native validation as a framework. Lecture in Yandex
The development of forms is one of the most crucial and difficult steps in creating web interfaces. The project should receive user data, check them and give the user feedback. Modern browsers provide the developer with an embedded API that allows you to progressively implement data validation using progressive enhancement - from HTML / CSS to JS. Is it possible today to abandon heavy libraries for validation? What are the benefits of native validation and how thorny is the way to use it? In his report at the FrontTalks conference, LOVATA technical director Pavel Lovtsevich reviewed the main aspects of working with the HTML5 Constraint Validation API.
- Hello everyone, my name is Pavel, I came from Minsk. I will tell you about the validation of web forms based on native, browser-built technologies.
I work as a technical director at LOVATA, and also work as a technical director at our grocery startup 2doc.by, this is a medical search with a B2B part, which consists in automating the work of medical centers.
I have been holding events in Minsk for almost 10 years. For a long time these were only Web Standard Days, but over the last year Ostap suffered, and immediately plus three events. It is possible to hang the medals like Brezhnev. Come to Minsk, we have a lot of cool activities, we will be friends with cities and communities.
')
I am sure there will not be a person in the hall who at least once would not make a web form in any form, at least one text field for receiving data. This is one of the most important pieces in the interface of websites and applications, because it directly affects the conversion and the success of the project.
There is a Beymard Research Institute that deals with usability research. They conducted research on 37 open sources, which, in turn, conducted independent research from 2012 to 2017 on the use of web forms and came to the following conclusions: almost 70% of users abandon their baskets. Of these, 60% leave them for the reason that at some point they were still not ready to start a purchase, but simply became acquainted with the product. At the same time, 27% of users clearly indicated that they abandoned order placement due to the fact that the web form was too complicated. They are faced with certain problems when working with her. Either it was too long. The average number of fields in the checkout form in this study was about 15. Or there were problems with validation. Anyway, the web form has fundamentally influenced the conversion of all these stores.
Based on this study, it was concluded that interface improvements to web forms could lead to a 35 percent improvement in conversion rates. Taking into account the size of the market, the United States in e-commerce is $ 260 billion, we will only make the web form better, reduce the number of fields from 15 to 7–8, and make a good, relevant validation. And the industry will help out an additional 260 billion a year.
Validation is one of the most important stages of working with users' web forms. Previously, we had non-native ways, there were many of them, each writing a library to himself. Currently, nQM libraries for jQuery are very popular. To simply validate the form fields, you drag a jQuery bundle that weighs 80 KB.
Everything can be simplified by using the tools built into the browser.
Validation is such a serious thing that even there is a special ISO standard that stands for the definition of validation.
What is the purpose of validation? First, getting the correct data in the correct format for later processing. Secondly, protecting the user from all sorts of data interception. And finally, the protection of the application. We do not want to be hacked through the web form and get access to the user data that he entered earlier.
What is the most important field of client validation, without which there is nowhere? Validation on the server! This is the main method of validation, it is responsible for security. Client validation is primarily what affects the user experience, the very same UX. Good validation helps increase conversion.
What does good validation consist of? A study was conducted, Martin Trader based on several sources, including a large study of Luke Wroblewski, a renowned usability specialist. He came to the following conclusions that, first, validation should be in the right place. This refers to the form of a message about an error, where we display a user error message so that it is convenient for him to work with it.
Secondly, at the right time - inline validation, no one wants to fill out the entire form, and at the end when you see, we have some mistakes, come back and start over. Worse, if we lose some data.
Thirdly, a suitable color. We are accustomed to see that in the forms of the field with errors somehow highlighted in red, but research shows that one of the best options is still orange. It doesn’t put so much pressure on the user, plus it’s a color that can see color blind.
Fourth, understandable language. This is a broad concept. We must explicitly inform the user that he did not do it in the right way and how to fix it, and not just highlight the field that was mistakenly filled in, and leave the user to deal with him one by one.
A study by Luke Wroblewski suggests that inline validation leads to an increase in the following indicators. 22% increase in the success of completing the form; 22% decrease in the number of errors when filling it; user satisfaction is growing by 31%; time to complete the web form is reduced by 42% with other things being equal; and users' eyes are less strained during inline validation, since they do not have to constantly run through different fields, thus, the number of eye fixations on the web form is reduced by 47%.
The main theme of my report is a special API built into the browser for a long time, but so far this topic has not been actively promoted.
I took up this topic this year, there have also been several studies, for example, Peter Paul Koch from Holland did a lot of research on using native validation in the browser, and Chris Ferdinandi also wrote a large series of articles.
What can we do with native validation?
In terms of support, everything is pretty good. In this case, we mean basic support, which means that we can indicate the fields as mandatory and catch their state of validity or invalidity, whether the field is filled in or not.
In this situation, if the browser supports Form validation, we say that it supports some native JS API methods.
The first way to enable validation is to simply mark the field using the Required attribute as mandatory.
On the left, the field is marked with the required attribute, not on the right. Immediately on the form and on the elements of this form are hung valid and invalid pseudo-classes, which highlight the state of their state. As you can see, the form itself can also catch the state of validity or non-validity, “listening” to the state of the fields inside. The inner frame can also catch these states.
If we try to enter something here, we will see that the form and fieldset received a forwarded state of validity, and the form can be sent.
In terms of support, we only have problems with Edge and IE. They consist in the fact that in these browsers the fieldset and form do not support the state of validity / non-validity. But I do not see a big problem in this, because I have not met cases in my practice when it would be very important for us to catch this state on these elements.
In the above form, the button was initially highlighted in green, because In browsers, this form element is always in a state of validity, and only in Firefox, there is a special vendor pseudo-class and only for the button when it is input to type submit. Separate narrow history, I doubt that you may need it.
The second way to enable validation is with an attribute. We can set the length of the string in the field, limit it to the maximum and minimum value, specify the pattern, etc.
Required support all kinds of form fields.
With the length of the string (minlength / maxlength), it is important to understand that in addition to such field types as file, checkbox, radio, boolean types, there are field types that do not support this type of restriction. These are numeric fields, for example, either type number or type data and all its variations, because they have their own special limiters, which estimate not the length of the line, but the value of the value entered in the field.
For fields whose values ​​can be estimated in magnitude, the attributes min and max are used as a constraint.
Step is also used with similar fields. Its main task is to set the step values ​​that we can enter in the field. This may be a multiplicity of a certain number, time interval, etc.
Pattern applies to all text fields except numeric and date fields. This is the most well-supported attribute element in forms, with the help of which including we can write folbacks for browsers that, for one reason or another, do not understand the purpose of a certain type of field, which we will consider further.
The third type of validation inclusion is an indication of a specific field type, its semantics. In addition to the standard ones - text, password, file, text area - you can drop the select here, there are also number, range, email, tel, url and date. From date, so far everything is not very good in terms of support, but after two versions of Firefox, we will have almost the best date picker, only Safari will be left to catch up.
Let's try to create a form according to the method of progressive improvement. We all go to the situation where for the last 10 years we have collected everything in bundles, all our scripts, styles, and as HTTP 2 spreads, sharpened to multi-threaded download of our assets to the pages, we will gradually refuse to glue the files. In our case, it will be more likely that situations will arise where some of the resources may be underutilized. Yes, we can catch such states with various JS APIs, react to them in one way or another, but at the same time, if we do validation of the form using CSS, we will be able to improve the user experience in some way before the JS works.
Imagine that this is a kind of abstract order form. Everything is highlighted in green, there are no restrictions. If we set a mandatory field restriction, we will immediately see which fields will become highlighted in red. Let's enter something in the required field, the field is filled, everything has become ok.
( Working with the form in the video from 13:30 - editor's note.) Support for the type number is quite good, only in Edge there is a problem in that it does not display special arrow controls in the field that allow the user not to enter data, but Switch them using these arrows. There is a feature in Firefox that it allows you to enter a non-numeric value in this field type, and Chromium browsers and Edge, in principle, will not allow this. This is more correct behavior, because it helps prevent the creation of a situation when an error occurs. Using this field we will restrict the corresponding order field in our form.
What is wrong with the form I discovered at Sheremetyevo Airport? The wrong field type is used here, but why? A type number is used, intended for fields that take on values ​​of the form of a floating-point number. If this is just a set of numbers, as in this case, this is just a code in SMS, then this is not the situation when you need a type number. In this situation, you should use the usual type text with a pattern that limits the range of characters that can be driven here.
Exactly the same situation in the form of a password recovery on Instagram. This is a typical wrong case for using the number type for fields. Do not do this, it is wrong.
There are three more special semantic field types. The first is an e-mail. Its primary meaning is to validate an e-mail. It has a fairly soft validation for RFC 822, which allows for the presence of e-mail on localhost, so you default on a similar field if you just enter a certain value before the dog symbol and after without specifying the top-level domain.
Also, the purpose of this field is the inclusion of special keys on the virtual keyboard of your devices when clicking the e-mail symbol in your e-mail box will appear on the keyboard.
The tel type does not have any special restrictions on the pattern, the telephone number formats are too different worldwide. Its main task is to include a numeric keypad on the device, because when typing phones, in most cases you do not need letters.
The URL type works in a similar way as email, there is enough valid validation that allows you to actually specify localhost without specifying a domain. These requirements can be tightened using the pattern attribute.
Let's try to tighten in our form restrictions. In addition to the fact that we set the type number, we will hypothetically present that the user can place an order for at least two units of goods and no more than 20.
We have address and city fields. We believe that a city of less than two letters in principle can not exist, and we need to deliver. We limit this field to two characters, and suppose that there is hardly a city with a name greater than 100 characters. But with maximum string length restrictions, always be careful. When validating the same e-mail and so on, you can never be sure until the end what the real value may be maximum. In any case, in the fields, even from a security point of view, it is worthwhile to limit the length of the field, but to make it comfortable enough to avoid a situation where you did not get into the real data that can be entered there.
Pattern attribute support is quite good, there are no problems anywhere. Safari on iOS version 10.2 had a problem with the fact that when the pattern was set for the field, the form submitted, despite the fact that the invalid data event was lit.
The main features of the pattern are the ability to set ranges of values, specify only characters of numbers or letters, variable values ​​and set the range of the minimum and maximum length of a string.
Let's try to validate the pattern. I'm from Minsk, we have all the zip codes start at 220, only the last three numbers change.
You see the usual Perl-like regular program we are used to in JS. It should be noted that the usual characters of the beginning and end of the line, in the case of use with the Constraint Validation API, can be omitted. A shorter recording without them will work the same.
I specified the title attribute, a standard hint attribute, that pops up when you hover over an element. In combination with a text field with a pattern set, this title attribute will pop up in a native tooltip informing the user that he has entered incorrect data. This is the only way for a single field type to set the contents of this message without using JS.
What are the obvious bugs at this stage and how can we solve them?
( Work with the form in the video since 19:40 - editor's note.) The left field is mandatory, it has a maximum character limit of four characters. You see six characters. This is a rather unpleasant moment, implemented in all browsers in the same way, which is that if we have the default value of our field exceeds our limit, then the flag of invalidation will not be lit.
If we try to change it, the cursor does not allow, because the maxlength attribute does not allow you to enter more than the allowable number of characters, it works the same way in all browsers.
But as soon as I try to remove one element, this event immediately triggers. A case when you give a user a field that is already filled with pre-invalid data is quite unusual, but be aware of such a feature.
For minimum values ​​the same. Here at least 4 is set, 2 is entered - valid. Begin to enter - invalid. Reached 4 - valid.
Edge has a problem with the fact that minlength is not supported as an attribute. But you can get around this by simply using a pattern that will work in conjunction with your minlength and maxlength attributes, and it will take precedence.
Type number. If the browser does not understand some special type of field, then the default behavior is that it will be folded to the usual type text. If you have a case when some very old browser does not support the type number, but you need to do this, you can specify a regularity that allows you to validate only the numbers valid in this type of field.
If we want to set a limit on the value, the regular cannot calculate the value of the value, but we can set the ranges of acceptable values ​​using similar techniques. Naturally, this is not very convenient, and the greater the permissible value, the greater will be the regular interval. Therefore, it is a working case, but very private, because it can be difficult and inconvenient to work with it. But he works.
Type e-mail. The default RFC 822, which allows for the presence of e-mail on localhost. Naturally, we are not satisfied with this, we want to get a real e-mail of the user, so we can improve the validation of an already existing semantic field by adding the correct pattern.
I did not drive the real pattern, it would be too big, you can google the real pattern for RFC 822. The pattern for the usual type of e-mail is also easily googled.
Another rather important field type is date. Firefox will also come with support of this type soon. In our form, this is not the case, but I will show a method in which you can also do validation without a JS of this type of field.
For example, if we want to receive data from a user about a date in the format YYYY-MM-DD, then a regular schedule in the pattern attribute will help in this matter.
( Work with the form in the video from 23:25 - approx. Ed.) Let's try to fill out our form. The language in which the standard fill out message is displayed is not the default OS locale, it is the browser locale. If you need to manage language, number formats, money, dates, etc., you can use JS API - Internationalization for this purpose to customize these things. At this stage, we only work with the CSS part of validation.
2. 1 — . , — « 2», 12 , .
, , . , .
e-mail. title, , , e-mail, RFC 822.
. , title.
— , .
? . , . , , , , , , .
:user-error WHATWG, , . , , .
:user-invalid W3C, .
, :placeholder-shown. , . , , ?
-, , , . , , , , .
, , .
, , , .
. , .
, Edge, , , — , JS, , .
( 27:25 — . .) , . - — . , — . , , - , - .
.
— . .
. , , .
, Chromium- , , .
JS.
Constraint Validation API . -, checkValidity, true/false, .
reportValidity , . setCustomValidity .
willValidate, , submit , , , novalidate .
Valiidity , , , .
, reportValidity() — , .
( 29:30 — . .) Chrome . . , Chrome , , , . .
, , .
, , .
setCustomValidity , .
, API, , .
Validity , , , , , .
, , .
, , . , API.
. ? , , , , , , .
, Validity.
, , , , . Validate novalidate, , , .
blur , .
hasError, , , , Validity.
, , , , .
. e-mail, URL, e-mail, , .
, minLength, maxLength, , , . .
title, .
.
.
, .
error .
id , .
? div , . .
div aria-, , , id.
.
, .
error , aria-.
id .
, , , , submit .
event listener, , .
preventDefault , .
, id , , . , Chrome, , .
. ( 35:40 — . .) , , , .
, . Validate JS, . API , , , . , — , Validate . — .
Polyfill, IE9 .
- 2017 Samsung Internet. , API , . , , API .
API . , JS, .
, , 6 , 2,7 . : jQuery jQuery 80 .
Using this API allows you to understand their features, give feedback to the authors of the specification about what is convenient and what is not. At one time, jQuery also appeared as an API on top of the API, and the best things from jQuery went into the ECMAScript specification. I am convinced that the more developers will access this API and use it in their work, the more feedback there will be and the sooner the API will be brought to a normal state.
When the API is brought to such a state that no layers are needed, native validation will work much faster than any script in the script that you connect to the script from the outside. Andrey Sitnik also says that you can write a more convenient API over any API and use it safely. That's all, thank you.
- Hello everyone, my name is Pavel, I came from Minsk. I will tell you about the validation of web forms based on native, browser-built technologies.
I work as a technical director at LOVATA, and also work as a technical director at our grocery startup 2doc.by, this is a medical search with a B2B part, which consists in automating the work of medical centers.
I have been holding events in Minsk for almost 10 years. For a long time these were only Web Standard Days, but over the last year Ostap suffered, and immediately plus three events. It is possible to hang the medals like Brezhnev. Come to Minsk, we have a lot of cool activities, we will be friends with cities and communities.
')
I am sure there will not be a person in the hall who at least once would not make a web form in any form, at least one text field for receiving data. This is one of the most important pieces in the interface of websites and applications, because it directly affects the conversion and the success of the project.
There is a Beymard Research Institute that deals with usability research. They conducted research on 37 open sources, which, in turn, conducted independent research from 2012 to 2017 on the use of web forms and came to the following conclusions: almost 70% of users abandon their baskets. Of these, 60% leave them for the reason that at some point they were still not ready to start a purchase, but simply became acquainted with the product. At the same time, 27% of users clearly indicated that they abandoned order placement due to the fact that the web form was too complicated. They are faced with certain problems when working with her. Either it was too long. The average number of fields in the checkout form in this study was about 15. Or there were problems with validation. Anyway, the web form has fundamentally influenced the conversion of all these stores.
Based on this study, it was concluded that interface improvements to web forms could lead to a 35 percent improvement in conversion rates. Taking into account the size of the market, the United States in e-commerce is $ 260 billion, we will only make the web form better, reduce the number of fields from 15 to 7–8, and make a good, relevant validation. And the industry will help out an additional 260 billion a year.
Validation is one of the most important stages of working with users' web forms. Previously, we had non-native ways, there were many of them, each writing a library to himself. Currently, nQM libraries for jQuery are very popular. To simply validate the form fields, you drag a jQuery bundle that weighs 80 KB.
Everything can be simplified by using the tools built into the browser.
Validation is such a serious thing that even there is a special ISO standard that stands for the definition of validation.
What is the purpose of validation? First, getting the correct data in the correct format for later processing. Secondly, protecting the user from all sorts of data interception. And finally, the protection of the application. We do not want to be hacked through the web form and get access to the user data that he entered earlier.
What is the most important field of client validation, without which there is nowhere? Validation on the server! This is the main method of validation, it is responsible for security. Client validation is primarily what affects the user experience, the very same UX. Good validation helps increase conversion.
What does good validation consist of? A study was conducted, Martin Trader based on several sources, including a large study of Luke Wroblewski, a renowned usability specialist. He came to the following conclusions that, first, validation should be in the right place. This refers to the form of a message about an error, where we display a user error message so that it is convenient for him to work with it.
Secondly, at the right time - inline validation, no one wants to fill out the entire form, and at the end when you see, we have some mistakes, come back and start over. Worse, if we lose some data.
Thirdly, a suitable color. We are accustomed to see that in the forms of the field with errors somehow highlighted in red, but research shows that one of the best options is still orange. It doesn’t put so much pressure on the user, plus it’s a color that can see color blind.
Fourth, understandable language. This is a broad concept. We must explicitly inform the user that he did not do it in the right way and how to fix it, and not just highlight the field that was mistakenly filled in, and leave the user to deal with him one by one.
A study by Luke Wroblewski suggests that inline validation leads to an increase in the following indicators. 22% increase in the success of completing the form; 22% decrease in the number of errors when filling it; user satisfaction is growing by 31%; time to complete the web form is reduced by 42% with other things being equal; and users' eyes are less strained during inline validation, since they do not have to constantly run through different fields, thus, the number of eye fixations on the web form is reduced by 47%.
The main theme of my report is a special API built into the browser for a long time, but so far this topic has not been actively promoted.
I took up this topic this year, there have also been several studies, for example, Peter Paul Koch from Holland did a lot of research on using native validation in the browser, and Chris Ferdinandi also wrote a large series of articles.
What can we do with native validation?
In terms of support, everything is pretty good. In this case, we mean basic support, which means that we can indicate the fields as mandatory and catch their state of validity or invalidity, whether the field is filled in or not.
In this situation, if the browser supports Form validation, we say that it supports some native JS API methods.
The first way to enable validation is to simply mark the field using the Required attribute as mandatory.
On the left, the field is marked with the required attribute, not on the right. Immediately on the form and on the elements of this form are hung valid and invalid pseudo-classes, which highlight the state of their state. As you can see, the form itself can also catch the state of validity or non-validity, “listening” to the state of the fields inside. The inner frame can also catch these states.
If we try to enter something here, we will see that the form and fieldset received a forwarded state of validity, and the form can be sent.
In terms of support, we only have problems with Edge and IE. They consist in the fact that in these browsers the fieldset and form do not support the state of validity / non-validity. But I do not see a big problem in this, because I have not met cases in my practice when it would be very important for us to catch this state on these elements.
In the above form, the button was initially highlighted in green, because In browsers, this form element is always in a state of validity, and only in Firefox, there is a special vendor pseudo-class and only for the button when it is input to type submit. Separate narrow history, I doubt that you may need it.
The second way to enable validation is with an attribute. We can set the length of the string in the field, limit it to the maximum and minimum value, specify the pattern, etc.
Required support all kinds of form fields.
With the length of the string (minlength / maxlength), it is important to understand that in addition to such field types as file, checkbox, radio, boolean types, there are field types that do not support this type of restriction. These are numeric fields, for example, either type number or type data and all its variations, because they have their own special limiters, which estimate not the length of the line, but the value of the value entered in the field.
For fields whose values ​​can be estimated in magnitude, the attributes min and max are used as a constraint.
Step is also used with similar fields. Its main task is to set the step values ​​that we can enter in the field. This may be a multiplicity of a certain number, time interval, etc.
Pattern applies to all text fields except numeric and date fields. This is the most well-supported attribute element in forms, with the help of which including we can write folbacks for browsers that, for one reason or another, do not understand the purpose of a certain type of field, which we will consider further.
The third type of validation inclusion is an indication of a specific field type, its semantics. In addition to the standard ones - text, password, file, text area - you can drop the select here, there are also number, range, email, tel, url and date. From date, so far everything is not very good in terms of support, but after two versions of Firefox, we will have almost the best date picker, only Safari will be left to catch up.
Let's try to create a form according to the method of progressive improvement. We all go to the situation where for the last 10 years we have collected everything in bundles, all our scripts, styles, and as HTTP 2 spreads, sharpened to multi-threaded download of our assets to the pages, we will gradually refuse to glue the files. In our case, it will be more likely that situations will arise where some of the resources may be underutilized. Yes, we can catch such states with various JS APIs, react to them in one way or another, but at the same time, if we do validation of the form using CSS, we will be able to improve the user experience in some way before the JS works.
Imagine that this is a kind of abstract order form. Everything is highlighted in green, there are no restrictions. If we set a mandatory field restriction, we will immediately see which fields will become highlighted in red. Let's enter something in the required field, the field is filled, everything has become ok.
( Working with the form in the video from 13:30 - editor's note.) Support for the type number is quite good, only in Edge there is a problem in that it does not display special arrow controls in the field that allow the user not to enter data, but Switch them using these arrows. There is a feature in Firefox that it allows you to enter a non-numeric value in this field type, and Chromium browsers and Edge, in principle, will not allow this. This is more correct behavior, because it helps prevent the creation of a situation when an error occurs. Using this field we will restrict the corresponding order field in our form.
What is wrong with the form I discovered at Sheremetyevo Airport? The wrong field type is used here, but why? A type number is used, intended for fields that take on values ​​of the form of a floating-point number. If this is just a set of numbers, as in this case, this is just a code in SMS, then this is not the situation when you need a type number. In this situation, you should use the usual type text with a pattern that limits the range of characters that can be driven here.
Exactly the same situation in the form of a password recovery on Instagram. This is a typical wrong case for using the number type for fields. Do not do this, it is wrong.
There are three more special semantic field types. The first is an e-mail. Its primary meaning is to validate an e-mail. It has a fairly soft validation for RFC 822, which allows for the presence of e-mail on localhost, so you default on a similar field if you just enter a certain value before the dog symbol and after without specifying the top-level domain.
Also, the purpose of this field is the inclusion of special keys on the virtual keyboard of your devices when clicking the e-mail symbol in your e-mail box will appear on the keyboard.
The tel type does not have any special restrictions on the pattern, the telephone number formats are too different worldwide. Its main task is to include a numeric keypad on the device, because when typing phones, in most cases you do not need letters.
The URL type works in a similar way as email, there is enough valid validation that allows you to actually specify localhost without specifying a domain. These requirements can be tightened using the pattern attribute.
Let's try to tighten in our form restrictions. In addition to the fact that we set the type number, we will hypothetically present that the user can place an order for at least two units of goods and no more than 20.
We have address and city fields. We believe that a city of less than two letters in principle can not exist, and we need to deliver. We limit this field to two characters, and suppose that there is hardly a city with a name greater than 100 characters. But with maximum string length restrictions, always be careful. When validating the same e-mail and so on, you can never be sure until the end what the real value may be maximum. In any case, in the fields, even from a security point of view, it is worthwhile to limit the length of the field, but to make it comfortable enough to avoid a situation where you did not get into the real data that can be entered there.
Pattern attribute support is quite good, there are no problems anywhere. Safari on iOS version 10.2 had a problem with the fact that when the pattern was set for the field, the form submitted, despite the fact that the invalid data event was lit.
The main features of the pattern are the ability to set ranges of values, specify only characters of numbers or letters, variable values ​​and set the range of the minimum and maximum length of a string.
Let's try to validate the pattern. I'm from Minsk, we have all the zip codes start at 220, only the last three numbers change.
You see the usual Perl-like regular program we are used to in JS. It should be noted that the usual characters of the beginning and end of the line, in the case of use with the Constraint Validation API, can be omitted. A shorter recording without them will work the same.
I specified the title attribute, a standard hint attribute, that pops up when you hover over an element. In combination with a text field with a pattern set, this title attribute will pop up in a native tooltip informing the user that he has entered incorrect data. This is the only way for a single field type to set the contents of this message without using JS.
What are the obvious bugs at this stage and how can we solve them?
( Work with the form in the video since 19:40 - editor's note.) The left field is mandatory, it has a maximum character limit of four characters. You see six characters. This is a rather unpleasant moment, implemented in all browsers in the same way, which is that if we have the default value of our field exceeds our limit, then the flag of invalidation will not be lit.
If we try to change it, the cursor does not allow, because the maxlength attribute does not allow you to enter more than the allowable number of characters, it works the same way in all browsers.
But as soon as I try to remove one element, this event immediately triggers. A case when you give a user a field that is already filled with pre-invalid data is quite unusual, but be aware of such a feature.
For minimum values ​​the same. Here at least 4 is set, 2 is entered - valid. Begin to enter - invalid. Reached 4 - valid.
Edge has a problem with the fact that minlength is not supported as an attribute. But you can get around this by simply using a pattern that will work in conjunction with your minlength and maxlength attributes, and it will take precedence.
Type number. If the browser does not understand some special type of field, then the default behavior is that it will be folded to the usual type text. If you have a case when some very old browser does not support the type number, but you need to do this, you can specify a regularity that allows you to validate only the numbers valid in this type of field.
If we want to set a limit on the value, the regular cannot calculate the value of the value, but we can set the ranges of acceptable values ​​using similar techniques. Naturally, this is not very convenient, and the greater the permissible value, the greater will be the regular interval. Therefore, it is a working case, but very private, because it can be difficult and inconvenient to work with it. But he works.
Type e-mail. The default RFC 822, which allows for the presence of e-mail on localhost. Naturally, we are not satisfied with this, we want to get a real e-mail of the user, so we can improve the validation of an already existing semantic field by adding the correct pattern.
I did not drive the real pattern, it would be too big, you can google the real pattern for RFC 822. The pattern for the usual type of e-mail is also easily googled.
Another rather important field type is date. Firefox will also come with support of this type soon. In our form, this is not the case, but I will show a method in which you can also do validation without a JS of this type of field.
For example, if we want to receive data from a user about a date in the format YYYY-MM-DD, then a regular schedule in the pattern attribute will help in this matter.
( Work with the form in the video from 23:25 - approx. Ed.) Let's try to fill out our form. The language in which the standard fill out message is displayed is not the default OS locale, it is the browser locale. If you need to manage language, number formats, money, dates, etc., you can use JS API - Internationalization for this purpose to customize these things. At this stage, we only work with the CSS part of validation.
2. 1 — . , — « 2», 12 , .
, , . , .
e-mail. title, , , e-mail, RFC 822.
. , title.
— , .
? . , . , , , , , , .
:user-error WHATWG, , . , , .
:user-invalid W3C, .
, :placeholder-shown. , . , , ?
-, , , . , , , , .
, , .
, , , .
. , .
, Edge, , , — , JS, , .
( 27:25 — . .) , . - — . , — . , , - , - .
.
— . .
. , , .
, Chromium- , , .
JS.
Constraint Validation API . -, checkValidity, true/false, .
reportValidity , . setCustomValidity .
willValidate, , submit , , , novalidate .
Valiidity , , , .
, reportValidity() — , .
( 29:30 — . .) Chrome . . , Chrome , , , . .
, , .
, , .
setCustomValidity , .
, API, , .
Validity , , , , , .
, , .
, , . , API.
. ? , , , , , , .
, Validity.
, , , , . Validate novalidate, , , .
blur , .
hasError, , , , Validity.
, , , , .
. e-mail, URL, e-mail, , .
, minLength, maxLength, , , . .
title, .
.
.
, .
error .
id , .
? div , . .
div aria-, , , id.
.
, .
error , aria-.
id .
, , , , submit .
event listener, , .
preventDefault , .
, id , , . , Chrome, , .
. ( 35:40 — . .) , , , .
, . Validate JS, . API , , , . , — , Validate . — .
Polyfill, IE9 .
- 2017 Samsung Internet. , API , . , , API .
API . , JS, .
, , 6 , 2,7 . : jQuery jQuery 80 .
Using this API allows you to understand their features, give feedback to the authors of the specification about what is convenient and what is not. At one time, jQuery also appeared as an API on top of the API, and the best things from jQuery went into the ECMAScript specification. I am convinced that the more developers will access this API and use it in their work, the more feedback there will be and the sooner the API will be brought to a normal state.
When the API is brought to such a state that no layers are needed, native validation will work much faster than any script in the script that you connect to the script from the outside. Andrey Sitnik also says that you can write a more convenient API over any API and use it safely. That's all, thank you.
Source: https://habr.com/ru/post/348240/
All Articles