Day 71: Form Practice Was Needed + Notes

Read through a bunch on docs on HTML5 forms and how to use the Constraint Validation API to write custom form validations in JavaScript. I was surprised at how much I did not read. Learning on the fly is great for meeting project deadlines but taking the time out to read through the docs and write your own notes is the best. I feel like I own the material so much more this way. I love stack overflow but let’s be honest. I’m scanning for the solution, I’m not reading all the information in the comments and answers. This review was something I did not know I needed but I really appreciate. I now realize that I should get more comfortable working with the various browser APIs just like I need to get more comfortable with the various Node.js modules. Web workers and geolocation are definitely on the list. Hopefully I run into a project that gives me the excuse to revisit the topics and take some good notes.

TLDR;

Okay, so here are the highlights of what I did:

HTML -> Reviewed HTML input elements. Wrote notes on all the different input types available.
CSS -> Reviewed form pseudo-classes and pseudo-elements. I am working on adding them to my notes so that I have a clear reference point for future projects.
Practice -> Continued working on the Sign-Up Page project from “The Odin Project” Full Stack curriculum. I am working on some simple examples for custom form validation before moving back to the project itself and implementing a “Matching passwords” validation for the “confirm password” input field.

Rough Notes – JavaScript Form Validation (A.K.A. Constraint Validation)

Client-side form validation is a large component of front-end web development. However, it comes with it’s own quirks. For us to master form validation we must learn the two methods we can use to implement such validation.

Built-in form validation using HTML5 using intrinsic and basic constraints
JavaScript custom form validation using the Constraint validation API

In these notes I will cover the basics of form validation using the intrinsic and basic constraints and the built-in API with some examples for later reference.

As a side note; even with all the form checking and validation we perform we should never trust the data we are sending from the client to our server. We must perform both client-side validation and server-side validation to ensure the data we are receiving is safe, correct, and matching what we need to perform the desired operation. Nefarious actors can work to bypass client-side validations which is why we must always be safe and perform server-side checks as well.

HTML5 `<input/>` Elements and Constraint Attributes

HTML5 has helped to simplify some of the challenges involved in common form validation tasks by providing different <input> types like “email”, “number”, “password”, etc, and constraint attributes that we can include in each respective <input> element. These attributes help to provide some basic validation but if we want to perform more complex checks we still need to use JavaScript and the Constraint Validation API.

As mentioned above HTML5 introduced new mechanisms for forms.

It added new semantic types for the <input> element
It added intrinsic and basic constraint validation to ease the work of checking the form content on the client side.

With these additions, basic constraints can be checked, without the need for JavaScript, by setting new attributes; more complex constraints can be tested using the Constraint Validation API.

This intrinsic and basic validation doesn’t require much JavaScript and has better performance in most cases. However, it is not as customizable as JavaScript validation.

HTML5 `<input/>` Element Types

There are a variety of <input> types that come default in HTML5. Using specific types with applicable constraints allow for intrinsic (built-in) form validations.

type="text" (default)
type="email"
type="password"
type="search"
type="tel"
type="url"
type="number"
type="range"
type="datetime-local"
type="month"
type="time"
type="week"
type="color"

HTML5 `<input/>` Constraints

Semantic Input Types Constraints

There are a some input types that by default have constraints placed on them. For example an input with type=number cannot accept an input other than a number. Similarly:

type=email -> The value must be a syntactically valid email address, which generally has the format username@hostname.tld
type=url -> The value must be an absolute URL, as defined in the URL Living Standard

In both cases a violation of the constraint for each respective <input> will result in a TypeMismatch constraint violation.

Side Note: setting the multiple attribute on any input that allows for it will result in the constraints adjusting to accept comma separated values.

Validation attributes Constraints

JavaScript Contrainst Validation API

JavaScript running in the browser comes with a built-in API specifically for Form validation (A.K.A. constraint validation). It is fully customizable, but we need to construct it all ourselves (or use a library). This comes with a bit of a learning curve but provides us with a lot of freedom once learned.

These notes cover how to perform validations on HTML5 <input /> elements from within a linked JavaScript file.

Constraint Validation DOM Methods

Property                 Description
--------                 -----------

checkValidity()          Returns true if an input element contains valid data

setCustomValidity()      Returns true if an input element contains valid data

Constraint Validation DOM Properties

Property              Description
--------              -----------

validity              Contains boolean properties related to the validity of an input element.

validationMessage     Contains the message a browser will display when the validity is false.

willValidate          Indicates if an input element will be validated.

Validity Properties

These are the properties that exist on the inputElement.validity object.

Validity Properties

Property              Description
--------              -----------
customError	      Set to true, if a custom validity message is set.

patternMismatch	      Set to true, if an element's value does not match its pattern attribute.

rangeOverflow	      Set to true, if an element's value is greater than its max attribute.

rangeUnderflow	      Set to true, if an element's value is less than its min attribute.

stepMismatch	      Set to true, if an element's value is invalid per its step attribute.

tooLong	              Set to true, if an element's value exceeds its maxLength attribute.

typeMismatch	      Set to true, if an element's value is invalid per its type attribute.

valueMissing	      Set to true, if an element (with a required attribute) has no value.

valid	              Set to true, if an element's value is valid.

Example using validity property rangeOverflow to display a ‘too large’ message to the user when the User input value is larger than the accepted maximum value.

<input id="id1" type="number" max="100">
<button onclick="myFunction()">OK</button>

<p id="demo"></p>

<script>
function myFunction() {
  let text = "Value OK";
  if (document.getElementById("id1").validity.rangeOverflow) {
    text = "Value too large";
  }
}
</script>

Example using validity property rangeUnderflow to display a ‘too small’ message to the user when the User input value is smaller than the accepted maximum value.

<input id="id1" type="number" min="100">
<button onclick="myFunction()">OK</button>

<p id="demo"></p>

<script>
function myFunction() {
  let text = = "Value OK";
  if (document.getElementById("id1").validity.rangeUnderflow) {
    text = "Value too small";
  }
}
</script>

Meta Data

Started On: 2022-05-12

References:

Goal For Round 7 of the #100DaysofCode Challenge

This is my seventh round of the “#100daysofcode” challenge. I will be continuing my work from round five and round six into round seven. I am currently working through the book “Cracking the Coding Interview” by Gayle Laakmann McDowell. My goal is to become more familiar with algorithms and data structures. This goal was derived from my goal to better understand operating systems and key programs that I use in the terminal regularly e.g. Git. This goal was in turn derived from my desire to better understand the fundamental tools used for coding outside of popular GUIs. This in turn was derived from my desire to be a better back-end developer.

I have no idea if my path is correct but I am walking down this road anyways. Worst case scenario I learn a whole bunch of stuff that will help me out on my own personal projects.

Post Views: 153