FAQ: Learn HTML: Form Validation - Introduction to HTML Form Validation

This community-built FAQ covers the “Introduction to HTML Form Validation” exercise from the lesson “Learn HTML: Form Validation”.

Paths and Courses
This exercise can be found in the following Codecademy content:

Introduction to HTML

FAQs on the exercise Introduction to HTML Form Validation

There are currently no frequently asked questions associated with this exercise – that’s where you come in! You can contribute to this section by offering your own questions, answers, or clarifications on this exercise. Ask or answer a question by clicking reply (reply) below.

If you’ve had an “aha” moment about the concepts, formatting, syntax, or anything else with this exercise, consider sharing those insights! Teaching others and answering their questions is one of the best ways to learn and stay sharp.

Join the Discussion. Help a fellow learner on their journey.

Ask or answer a question about this exercise by clicking reply (reply) below!

Agree with a comment or answer? Like (like) to up-vote the contribution!

Need broader help or resources? Head here.

Looking for motivation to keep learning? Join our wider discussions.

Learn more about how to use this guide.

Found a bug? Report it!

Have a question about your account or billing? Reach out to our customer support team!

None of the above? Find out where to ask other questions here!

3 posts were split to a new topic: Why are we taught divs when we are told to use header and nav instead?

A post was split to a new topic: What is the difference between GET and POST?


While the course is discussing client-side validation, one of the use cases is “This can also help us protect our server from malicious code or data from a malicious user.”

Unfortunately, this is incorrect, and might give people the wrong idea (i.e. that client-side validation has use as a security measure).
All of the other examples are correct though, but I heavily recommend that this one gets reworded or deleted, as relying on client-side validation for any security will lead to issues.

Form Validation seems to have jumped right into ‘Requiring an input’ and covered a few topics, but there seem to be other stuff not explained like: action, method, value, etc.

When doing the quiz at the end of the lesson, there are question I don’t seem to have covered? Also, when checking the Cheatsheet there are alot of things listed not covered. Is it expected to Google and do a self study for this particular ‘Form Validation’?

What does the below statement mean?

Shared among the different browsers are the benefits of using HTML5’s built-in client-side validation.

Different browsers implement client-side validation differently, but it leads to the same outcome.

Shared among the different browsers are the benefits of using HTML5’s built-in client-side validation.

The most popular web browsers offer form validation support. So, essentially, one code will work across browsers, and you should expect similar results whether you’re using Chrome, Safari, Firefox, Edge…

I’m not too sure how Internet Explorer fares in this regard. I think they’ve added support up to IE 10. Older than that and things get really messy anyway.

1 Like

“It also allows us to quickly give feedback to users for specific fields rather than having them fill in a form again if the data they input into the form was rejected.”
Is an example of this like when you finish filling out a page of a form and hit next but you didn’t fill something out correctly so it reloads that page but with red asterisks next to the fields you need to correct?


Explanation of action and Method:

Also, refer to this URL provided on this above lesson.

This explains the value and so on:

There would not be anything in the quiz not covered. I would recommend that you take notes and go over them at the end of the lesson before the quiz.

What can be an example of client side validations?

That would be correct. Browsers are designed to receive data from the host’s server (in this case, the webpage’s HTML, CSS, JS, etc. code) and convert it into a displayable graphic user interface. It’s a great built-in feature, but it’s also vulnerable to bad user input.

Bad input used to be spelling and grammar errors, incorrect personal information, and inappropriate words or phrases. Oftentimes it was just a bunch of gibberish (“alphabet soup”) because some kid thought it’d be fun to prank a legitimate blogger or business. Sure, it is fun but even accidental bad data can cause problems for anyone trying to provide goods or services to clients – especially if it involves payment or contact information.

Since QA’s gone automated to save money, the risk has become more prevalent.

Client-side validation allows the host’s servers to “borrow” your browser as their QA representative, through the also really cool built-in feature of cache, to ensure your input meets their requirements for accuracy and appropriate content.

Sounds kinda ridiculous, but Google’s even pointed out that users are the biggest security threat to any online business because of how easily they can exploit bugs and vulnerabilities. Given how the world’s become as we enter 2022, it’s just common sense to have somebody at the door (so to speak) to stop trouble before it begins.