OpenCourser
Learn skills that shape your future
Visit OpenCourser.com
Advanced Concepts: Understand URL encoding, date formatting, and the intricacies of the infamous input element.
Master Client-Side Validation: Understand progress bars, toggles, checkboxes, ranges, and tons more.
Handle Data Like a Pro: Learn how to grab and process form data on the server side using Node.js and PHP.
Join me on an exciting journey as we explore the nitty-gritty of web forms.
Let Me Share My Form-Building Expertise with You.
Advanced Concepts: Understand URL encoding, date formatting, and the intricacies of the infamous input element.
Master Client-Side Validation: Understand progress bars, toggles, checkboxes, ranges, and tons more.
Handle Data Like a Pro: Learn how to grab and process form data on the server side using Node.js and PHP.
Join me on an exciting journey as we explore the nitty-gritty of web forms.
Let Me Share My Form-Building Expertise with You.
Understanding how forms work is essential for becoming a skilled front-end developer. This course will empower you to implement your creative, dynamic ideas into your web projects. Mastering forms is a critical step toward full-stack development, giving you the control and knowledge to create effective user interactions. In this course, we’ll take a deep dive into web forms and their functionalities. Here are some key questions we’ll explore:
Why do we need to wrap our form elements within form tags?
How can you include a progress bar in your forms?
What are the best practices for customizing toggles and checkboxes?
Where does the data go once a user clicks the submit button?
How can you perform validation on your forms, both natively and using JavaScript?
How can users upload files through your forms?
What happens to the data once it arrives at the server?
By addressing these questions and more, you'll gain the skills needed to build advanced forms that enhance user engagement and experience. You'll also understand the full-stack process involved in handling form data effectively.
What You Will Learn
The fundamentals of HTML forms and their importance in web development.
You will understand at an advanced level how to create forms natively, and how powerful they can be in increasing conversions.
Techniques for creating dynamic forms that enhance interactivity.
Strategies for validating user input on both client and server sides.
Best practices for customizing form elements to fit your design needs.
From understanding the structure of forms to implementing validation techniques, you’ll gain the skills necessary to create dynamic and user-friendly web applications.
THE NITTY GRITTY OF WEB FORMS?
A web form is also known as an HTML form.
It’s a place where users can enter data that’s then sent to a server for processing. Web forms allow users to place orders on your site, to provide their name and email address to sign up for a newsletter, or to sign up as a member to your site and so forth.
What’s really great about web forms is that there is no “one size fits all”. You can use your artistic flare, and personal business acumen to create web forms with a particular length, format, content type and appearance.
By doing this course, you’ll be able to improve your web form usability, which will ultimately enhance user experience and get website visitors excited about completing your form and converting.
Why is this course so important?
Forms which are on point present an opportunity for a company to grow and capture loyalty.
A form can often be both a marketing tool and a necessity. A form that puts the user at ease, that evokes feelings of trust, will get filled out far more often than a form which looks (or is) complicated and confusing.
After completing my “Advanced Forms” course, you will be knowledgeable, confident and the “go-to” person for forms.
Let me share my form building skills with you
Understanding how forms work will equip you to become an awesome front-end programmer. Learn how to implement your creative, different and dynamic ideas into your website. Master forms and you’re half way to becoming a full stack web developer. Take control through understanding. Delivering a perfect, interactive and functional form is challenging.
In this course, I take a deep-dive into explaining web forms and how they work. Why do we need to wrap our form within <form> tags? How can you include a progress bar in a form? How can you customize a toggle or checkbox? Where does the data go once a user clicks on the submit button? How can you perform validation on your form? How can a user upload a file? What happens once the data arrives at the server? What are the different types of events we can listen to on forms? By understanding these questions, and many more in the course, you will be able to build advanced forms and better yet, understand the full stack process. In other words, you will be able to create dynamic forms that improve user engagement and experience.
WHAT THIS COURSE COVERS
This course is huge and comprehensive, from basics to advanced
This course will give you solid fundamentals and practicals regarding forms. It can be taken alone (you don’t need to do any other course) to achieve your goals. You will emerge from this course with an advanced understanding and practical experience with building forms. It will take you to the point where you will understand what method (GET or POST) to use when sending form data, how to define where the data goes, how to perform advanced client-side validation (checking errors on the form before it is sent to the server), how to write custom pattern validation rules (using regular expressions), how to run servers and how to view all HTTP request information. This is awesome knowledge. This course will captivate you and catapult you to the next level and set you well on your way to becoming a true Grandmaster in front-end form web development.
By the end of this course, you'll be able to “speak” and “walk” FORMS by gaining an understanding of how you can build it, manipulate it and style it in meaningful and practical ways. We dig deeper in every lecture, and this course has many bonus lectures which extend your knowledge base and test your skills.
Why should you learn so much about forms?
A web form is one of the best ways to get input from prospective clients and indirectly establish a relationship with them. The time you spend in bringing the user to your website should be matched with the time spent in perfecting the user experience with your web forms. It is surprising to see so many sites these days contain complex and frustrating web forms that cause a negative experience.
Ultimately, a web form allows your visitors to get in contact with you and to send information, such as an order, a catalogue request, or even a query, which is passed on to your database.
Can you begin to see how important forms are and how their use can be escalated?
THE MOST comprehensive FORMS course on Udemy
Successful programmers know more than rote learning a few lines of code.
They also know the fundamentals of how HTML code works behind the scenes.
This is particularly true when it comes to building forms.
If you’re wanting to become a full stack developer, you need to know, really know, how forms work. You need to understand how the browser URL encodes form data, how the browser sends data to a URL that you specify, and how to perform validation to ensure the user does not submit invalid data.
A unique approach
You will learn "why" things work and not just "how". Understanding advanced topics about forms (lURL encoding, accept-charset, multipart/form-data, regex, etc) is important as it will give you infinite possibilities and upskill you. Armed with this knowledge, you’ll be able to create forms that are tailored to your needs, and allow the form data to get submitted to a server via AJAX. You will be able to create forms that are customizable by the user (for example, if the user wants to change the color of the form theme). You can create a control on a form that displays the progress completion of the form and displays messages to the user along the way.
Can you begin to see how pivotal forms are and how important having knowledge about forms is?
How is this course different?
There are lots of courses that focus on web development. Many never get into the detail about how the HTML FORM element works behind the scenes – a skill that every full-stack developer needs to master in order to utilize potential.
In this course, I focus on the more advanced topics of true web development when it comes to forms. This includes understanding what all of the attributes on the <form> element mean, understanding the different <input> types in detail, what URL encoding is, and how data is sent over the wire to a server.
Practice makes perfect
Theory is theory … but there’s nothing like getting behind your computer and typing in code. That’s why we will be coding, laughing and pulling out our hair together as we code real life websites and exercises during this course.
I love practical examples, which is why we build multiple forms in this course, starting in section 1.
Is this course for you?
This course is designed for anyone eager to enhance their web development skills, regardless of your current level.
If you find yourself in any of the following categories, this course is perfect for you:
Aspiring Developers: You want to explore the world of programming and learn how to create dynamic and interactive web forms.
Front-End Enthusiasts: You’re looking to gain a deeper understanding of HTML forms and how they can improve user engagement.
Future Full-Stack Developers: You wish to understand how front-end JavaScript interacts with back-end technologies like Node.js and PHP.
Curious Learners: You have a basic grasp of web forms but want to dive deeper into advanced concepts like validation, URL encoding, and data handling.
Developers Seeking Mastery: You’ve taken other courses but feel you haven't fully grasped the intricacies of form elements and client-server interactions.
Right this second, your competitors are learning how to become better web developers.
Web development is a blazing hot topic at the moment, and in the foreseeable future. But you have a distinct advantage. This course offers memorable learning topics, actionable tactics and real-world examples.
Lets get started.
What do you get?
Lifetime access to all tutorial videos. No fees or monthly subscriptions.
Q&A support.
Quizzes, coding challenges, a test and assignments to help you learn.
I’ve allowed you to download all of my lectures for offline viewing.
Let's get excited about becoming a professional web developer, and to be able to confidently apply it to your own websites.
Let's get crackin'
A successful app in most cases requires the use of a form. A form allows a user to enter data that is then sent to a server for processing. So in a way they resemble a paper or database form. In all cases, the user fills out forms using text fields, radio buttons, checkboxes and the like.
On the face of it, everything seems simple.
But dig deeper, and there's a whole bunch to forms that most developers don't know much about. Things like the encryption type, the differences between a GET or POST request, the TONS of different form widgets and how a server actually grabs the data and does something with it.
This is an exciting course ... all about forms.
Creating a form is straightforward.
All you need to do is wrap your entire form code (which is written in HTML by the way) in the <form> element. Simple enough right.
And often we have attributes attached to the form, and the 2 most common attributes you'll see developers use are (1) the METHOD attribute and (2) the ACTION attribute. I'll discuss in this lecture the differences between them. But don't worry, we get into a LOT more detail later in this course. This is only a teaser.
We've seen that we have to wrap our form (written in HTML) in the <form> element.
But if you're anything like me, you want to know ....
WHY????
Great question, which is what I speak about in this lecture.
Sometimes we stand too close to the wall we can't see the painting. This is just a high level view of what we've covered so far.
Sometimes we stand too close to the wall that we can't see the painting. Thats why I always like to take a step back and recap along the way.
The remainder of this section we will be creating a form together.
It is going to be a simple form. But very important. Not only do we use toggles, dropdowns and input boxes, but we also style our form by using CSS flexbox.
If you are familiar with forms and CSS, then you are welcome to skip this section entirely. This is for those of you who are not yet familiar with the <form> element.
I can't wait.
It can be daunting to know which IDE or software application you should install to start coding.
In this short article I'll give you insight into what I use.
Before we build our HTML form, lets create our form header and also define our CSS variables for later use.
We started building our profile header in the previous lecture, but we didn't manage to finish. In this lecture I want to finalize the header so that we can get into the meat of this project - the <form> element.
Now its time to get into creating our form. Remember, we have to wrap our form inside the <form> tag. But as I previously mentioned, this does not do anything visually.
The first item I want to create in this form is a text input box where the user can type their profile name. This means we will be coding our first form widget together - the <input> tag.
Before we move on, lets review the <input> element. In fact, as you will discover in later sections, the <input> element is one of the MOST POWERFUL elements in an <html> document. There are tons of things we can do with the <input> element. So far, we've only seen it be used for the user writing in simple text.
The <input> element is powerful. <input> elements are essential for creating interactive forms that enable users to provide information, make choices, and submit data to servers.Libraries and frameworks leverage <input> elements to create custom input fields, date pickers, sliders, and other interactive components.
Coding up our <input> element is one thing. But the default styling is ... how do I say this ... AVERAGE at best!
So now lets use some of those CSS variables we defined in an earlier lecture and make this widget pop.
Remember what I said earlier - that the <input> element is one of the most powerful of ALL HTML ELMENTS!!!
Well, now we're also going to use the <input> element to create a simple email widget. The email widget comes with standard default browser validation which is also useful and improves UI / UX.
A radio button is basically a selection button. In other words, it gives the user the ability to toggle between different selections. Importantly, with radio buttons the user can only select ONE item within the entire group. If you want the user to have the ability to select multiple items, then there's another form widget for that (more on this later).
This lecture is a quick introduction to radio buttons and some of the most important things you need to remember when dealing with it.
Radio buttons are often used in forms and quizzes.
Enough talk! It's now time for us to open Visual Studio Code (our code editor) and start coding a radio button. Remember, its just an <input> element with its type attribute set to "radio". But usually (not always) we want our radio button group to have a heading and labels, so we will introduce the <fieldset> and <legend> elements in this lecture too.
Remember, a radio button is just a normal HTML <input> element, but with its type attribute set to "radio". We did, however, introduce other elements like <fieldset> and <legend> which can be particularly confusing for new programmers. Thats why I've put this lecture together, to give a birds eye view of how all these HTML elements work together.
Styling a radio button is a little more of a hassle than other HTML elements. Why? Because it does not work well with flexbox. But don't worry, in programming there are many ways to complete a task. So in this lecture I will show you how to style our radio buttons so that they look presentable.
The <input type="radio"> defines a radio button.
The interesting thing about radio buttons is that they are usually presented in radio groups. In other words, radio buttons are usually an entire collection of buttons that describe a set of related options. Importantly, only one radio button in a group can be selected at the same time.
A dropdown menu is a toggleable menu that allows the user to choose one value from a predefined list.
Dropdown menus are a great way to clean up a busy layout.
If done properly, dropdown menus can be a great navigation tool. Often dropdown menus are used to group pages in a certain category together, but they don’t have to be. Dropdown menus can also be used to organize categories in a blog, recipes on a food site, products on an ecommerce site and a bunch more.
In this lecture we look at creating our first dropdowns.
We've already seen the <input type="text"> widget, which gets the question: WHY DO WE NEED A TEXTAREA?
Great question.
The largest downside with the <input type="text"> widget is that it is only used for one line of text. Sometimes you need more. The <textarea> elements allows the user to input multi-line text. Its used to collect user inputs like comments or reviews.
The <textarea> element can hold an unlimited number of characters, and the text renders in a fixed-width font (usually Courier). The size of a text area is specified by the <cols> and <rows> attributes (or with CSS), which we'll get into more detail on later on in this course.
Later on, I will dedicate specific time talking about the <textarea> element. But for now, just realize that it is pretty powerful.
We all know checkboxes. You know, that box that can be toggled by the user to indicate a YES or NO choice. It is frequently found in HTML forms, dialog boxes, and in the GUIs of applications and operating systems.
Its easy to create a checkbox. Again, we will be using the famous <input> element. But this time, its type is set to checkbox. They are rendered by the browser as boxes that are checked (ticked) when activated, like you might see in an official government paper form. The exact appearance depends upon the browser you're using (Mozilla, Chrome, Safari, etc.). Generally a checkbox will be shown as a square but it may have rounded corners.
Its great having all the form controls. But the last piece of the puzzle is of course adding a button so that the user can decide to submit the form.
That is what we'll do in this lecture.
Oh, and one last thing we'll do is finish off the styling of the form so it looks complete.
I want to briefly summarize what the action and method attributes do before we move on. Why? Simple. These 2 attributes are usually always placed within a <form> element. They are vital because they allow us to tell the browser where we want to send the form data to, and how we would like to send that data.
I have also attached the final index and style sheet.
You've completed the first section of this course - well done.
I have attached the final project code to this lecture so feel free to download it and compare your file to mine.
Have fun, and see you in the next section.
WHOHOO! You're done with the first section. Nice!
Forms are crucial.
They are the money pages of websites, because most areas where you can input information into web pages are created using HTML forms.
The form data is then usually submitted to a server and the data is used in some way. For example, customer details can be stored in a database for later use, or a page can instantly update after a buyer chooses a product to look at or chooses to view comments on a blog post.
We haven't yet gone into detail about how forms work, but we have (at a high level anyway) seen how a form can be built. We've seen the <input> element, the <select> element and even the <textarea> element. But there are a ton more.
Before we move on, I want you to try and answer all of these questions.
Have fun, and see you in Section 2.
The <form> element is the cornerstone of modern web development.
This section is going to be epic.
I was literally walking to the shops and had a great analogy I wanted to share with you. The <form> element is just a wrapper or container. What I mean by this is that there is ZERO visual effects as a result of the <form> element.
This begs the question then, why have the <form> element at all? Why not just create our entire form directly inside the <body> tags?
Great question.
The short answer is that by using the <form> element, we have certain unique attributes that we can use that help us with our form.
The long answer is this entire section. Enjoy!
I want us to focus on the <form> element in this section. The <form> element is the wrapper for all of our form content. Although in theory you can choose to ignore it, in practice you should always have it.
The <form> element was designed to contain other form widgets and controls. It's mostly used to gather information from a user and it was introduced in the HTML2 specification (its been around a LONG time already).
We will be talking about many attributes in this course, but for now I want to remind you about the ACTION and METHOD attributes. We've mentioned them briefly before so you may remember what they do.
You can add attributes to any HTML element, and the <form> tag is no exception.
Attributes are always placed in the opening tag.
Important: the browser knows the standard attributes and automatically creates an attribute property on the DOM object. This just makes our lives a lot easier.
We are discussing the accept-charset attribute, which is a request HTTP header that defines which character encodings the client (browser) understands.
This is important because it gives you, the developer, power to define what characters you want your form to accept. In this lecture we will be looking at ISO which includes the 128 ASCII characters and a few more (like the British pound symbol). We will also look at the ASCII seven-bit encoding technique which assigns a number to each of the 128 characters used most frequently in American English.
The accept-charset attribute is a request HTTP header that defines which character encodings the client (browser) understands.
In the previous lecture we looked as ISO which inclues the 128 ASCII characters and a few more (like the British pound symbol). We also looked as the ASCII seven-bit encoding technique which assigns a number to each of the 128 characters used most frequently in American English.
But as I mentioned in the previous lecture, ASCII is just not enough. What about emojis or Chinese characters for example? Well, today we have Unicode (UTF) which will blow your mind.
Lets jump in.
We've spent a long time talking about the accept-charset attribute (and rightly so) but sometimes it can get very confusing.
Right now I want to teach you a few more things about the attribute which you'll hopefully find very interesting.
Don't get intimidated by all the theory so far.
All you need to know at this point is that as a developer, you have the flexibility to define what characters you want your users to write into your form. You do this with the accept-charset attribute on the form.
Most of the time, we don't even need to specify this attribute because by default, the encoding type is UTF-8.
Don't get lost in all of the other detail.
The burning question is what happens if you define a character encoding type, and then the user types in a character that is not recognized by that type?
Great question.
Firstly, the browser will not be able to URL encode the character straight away. It will first have to attempt to convert that character into something it understands. Different browsers may do different things, but at the time of filming this lecture, Chrome attempts to convert the character into its own character set. It is in fact Unicode decimal form.
The problem with this, however, is that the server expects to receive values in the %HH format, which means that the server may not be able to read the character the browser sends it.
Enough talk, lets jump into this lecture.
In the previous lecture you've seen that the URL consisted of a bunch of weird characters. Well, this is because the browser has to URL Encode everything that is sent inside of a URL.
I give you an introduction to why this is the case and what those numbers mean.
When a browser can't find the encoding reference for a character, the default approach is to then convert that character into something the browser can understand.
The browser does this by converting that character into a numerical character reference.
The important point to take from this is that the numerical character reference is in DECIMAL form that the browser understands - not necessarily the server.
Servers typically understand %HH values (i.e. hex values) and not decimal ones. This is why our theta character (which is represented by the character 952 in decimal form) will likely never be recognized by the server.
What is the solution?
Easy. All you need to do is choose the an encoding type that covers all your bases. And as I've mentioned, the default accept-charset attribute is UNKNOWN, which is whatever the encoding type of your HTML document is. This is UTF-8, which is great for us and is why we often don't have to worry about writing this attribute out explicitly in our code.
As you would guess, the name attribute specifies the name of a form.
Why do you need to name a form?
For most cases it doesn’t matter, but it allows you to quickly access your form by writing less code.
Once you assign a name to an element, it is registered on the document object itself. This means that you can refer to that element via document.name_of_element throughout your code.
Granted, it won’t work too well if you have multiple elements with the same name, but it does allow shortcuts. So if you have <form name="myForm" ...> then you can access it later via document.myForm.submit(); for example.
The accept attribute limits the file selection dialog to files with certain MIME types. In other words, it specifies the types of files that the server accepts (i.e. that can be submitted through a file upload).
However, as we will see in the lecture, the <form> accept attribute is no longer supported in HTML5. If you want to use it, then we need to do so on the <input> element instead.
When building forms and asking users to submit data on your site or web application, you’ll often want to do something with your data, right?
And thats why the action attribute is so important, because the action attribute is WHERE you want the form to send your data to. Specifically, the action attribute provides the URL of the script (which is usually on the server) that receives the information from the form and processes it. In case you were wondering (which you probably weren't) most of the servers keep these form processing programs in a bin known as Common Gateway Interface-binaries (cgi-bin).
Before we move onto the method attribute, I thought this will be a good time to stop and review the action attribute in action (see what I did there?).
We will build a simple HTML form together, submit data and extract it to the screen. A simple exercise I know, but one that will help you fully understand the purpose of the action attribute.
We've built our form, but now its time to submit the data and try extract its data from the URL.
But how do we do this?
Well, in the old days we had to implement detailed string parsing to get the part of the URL we wanted, but today we have native access to the URLSearchParams() API which is given to us by the browser.
This lecture shows you how it works.
I know what you may be thinking: "will this form ever be finished?"
Good news ... yes it will.
In this lecture I want us to finish off writing our code inside of our main index.html file. We will then have to access to the <h1> tag to change its innerHTML content so that we can make it dynamic.
Well done for following along.
The method attribute defines how data is sent.
The HTTP protocol provides several ways to perform a request but the most common being the GET method and the POST method.
The GET method is the method used by the browser to ask the server to send back a given resource: "Hey server, I want to get this resource." In this case, the browser sends an empty body. Because the body is empty, if a form is sent using this method the data sent to the server is appended to the URL.
Enough already, lets GET (see what I did there) into the lecture.
The POST method is a little different to GET.
It's the method the browser uses to talk to the server when asking for a response that takes into account the data provided in the body of the HTTP request.
Its like the browser asking the question: "Hey server, take a look at this data and send me back an appropriate result."
If a form is sent using this method, the data is appended to the body of the HTTP request. In other words, you don't get data appended to the URL.
POST request parameters can’t be saved in browser history, can’t be bookmarked, has no restriction on form data length, cannot be cached, and is more hack-proof.
On the other hand, GET request parameters can be archived in the browser history, can be bookmarked, it is easier to hack, has restriction on form data length, and can be cached.
HTTP is a protocol which allows the client (your browser) to fetch resources, such as HTML documents. It is the foundation of any data exchange on the web and it is a client-server protocol. Don't let this scare you. All this means is that requests are initiated by the recipient (the browser), and processed by the server.
Now, this is the interesting thing with HTTP. HTTP allows the submission of all method types (like GET, PUT, DELETE and POST) BUT the HTML specification for forms does not allow it. This has been a debate for quite some time now.
This lectures sheds some light on this.
Browsers do support PUT and DELETE, but it’s the HTML protocol for forms that only accepts POST and GET.
It can get quite confusing when starting out to find out what information is being sent with the HTTP request. Whats more is that the information is placed in different places depending on whether you are using a GET request or a POST request. This is a brief article that outlines where you can find the information.
We've seen how text files are sent over the internet (in the body of the HTTP request) but how are images sent over the wire?
I want to now move on to discuss another form attribute - the enctype.
As we will see, the enctype attribute specifies how the form-data should be encoded when submitting it to the server. Note: The enctype attribute can be used only if method="post" .
Theory is one thing, but looking at a practical example is just ... way better. In this lecture lets create a form and submit a GET request to see how the enctype attribute works.
When you make a POST request, you have to encode the data that forms the body of the request in some way.
HTML forms provide three methods of encoding.
application/x-www-form-urlencoded (the default)
multipart/form-data
text/plain
Work was being done on adding application/json, but that has been abandoned.
(Other encodings are possible with HTTP requests generated using other means than an HTML form submission. JSON is a common format for use with web services and some still use SOAP)
An infographic to help you remember the different types of encodings
We are still dealing with a POST request, but now I want to dig deeper into what exactly multipart/form-data does.
One of the things you would have noticed is that when we use multipart/form-data, the Content-Type contains a boundary to separate name/value pairs. The boundary acts like a marker of each chunk of name/value pairs passed when a form gets submitted.
The boundary is automatically added to a Content-Type of a request header by the browser. In other words, we have no control over how it is generated.
A quick summary.
The Boundary value can seem daunting when starting out - but don't stress. I have your back.
We're looking at quite an advanced example. The first step is setting up our HTML file.
The next step in our example is setting up a Node.js server.
With all our code done, we can now get to the point ... and that is, to examine why multipart/form-data may be better than application/x-www-form-urlencoded.
In summary, HTML forms provide three methods of encoding.
application/x-www-form-urlencoded (the default)
multipart/form-data
text/plain (don't ever use this)
When it comes to complicated forms, we often use enctype="multipart/form-data". This is used to upload files to the server. It means no characters will be encoded. To state this another way, we use this when a form requires binary data, like the contents of a file, to be uploaded and sent to a server.
For simple forms, it's okay to use the default enctype, which is application/x-www-form-urlended.
The rel attribute (short for relationship) specifies the relationship between the current document and the linked document/resource. Depending on the type of element, the allowed values for REL will differ. In this lecture we'll look at REL in the context of forms.
The autocomplete attribute set to “off” can prevent specific fields from being auto-filled. For example, a form might ask for a pet’s name. In this case, it's likely that the field will auto-fill incorrectly and cause problems (hence a valid reason to turn it off in this instance).
Some other points:
Values include “on” and “off”
Default is “on”
Possibly useful for extra security on password fields
Lets create a very simple form and see autocomplete in action.
A very quick summary of what we've learnt about the autocomplete attribute.
The novalidate is a <form> attribute that we use to turn off validation for a form. In other words, we're telling the browser to ignore any validation it would normally perform.
Why would you ever want to use this?
A few reasons come to mind ... you may want to perform your own client-side validation (create your own validation bubbles) or you may want your server to validation everything.
Lets code up an example of asking the user to enter an even number only and see how novalidate works.
p.s. I know I said you can use novalidate on a per control basis, but this is only a half truth. We can only do this on a few controls and when we do, we have to call it formnovalidate.
The target attribute specifies a name or a keyword to the browser, that indicates where to display the response that is received after the user has submitted the form.
There are 5 values it can take:
_blank: The response is displayed in a new window or tab
_self: The response is displayed in the same frame (this is the default type)
_parent: The response is displayed in the parent frame
_top: The response is displayed in the full body of the window
framename :The response is displayed in a named iframe
Lets now look at an example using iframes. I've included the files so you don't have to type everything up yourself.
Lets finish off this section by looking at a real life example of a form and how it was created. You'll see that we have covered all of the attributes present on the form. WELL DONE!
In this section we looked exclusively at the <form> element.
I did this because it is so very important to master the fundamentals before getting more advanced.
Well done and see you in the next section about the MOST powerful form widget - the <input> element.
Web browsers request pages from web servers by using a URL. But did you know that the characters inside of a URL have to adhere to a set of predefined rules?
These rules state that only certain ASCII characters are allowed in the URL.
But we already know that ASCII is limited in scope, which is why we need URL Encoding. URL encoding converts non-ASCII characters into a format that can be transmitted over the Internet, and it does this by replacing unsafe ASCII characters with a "%" followed by two hexadecimal digits.
URL encoding converts non-ASCII characters into a format that can be transmitted over the Internet. URL encoding replaces non-ASCII characters with a "%" followed by hexadecimal digits.
As an example, URLs cannot contain spaces, and so URL encoding normally replaces a space with a plus (+) sign, or %20.
URL encoding can get complicated. In the previous lecture I said that non-ASCII characters have to be percent encoded. But if this were that simple, then why can we see international characters in the URL address bar ?
In the next few lectures we will be digging deeper into this.
URL stands for Uniform Resource Locator. A URL is nothing more than the address of a given unique resource on the Web. In theory, each valid URL points to a unique resource such as an HTML page, a CSS document, an image, etc.
URLs consist of multiple parts -- including a protocol and domain name -- that tell a web browser how and where to retrieve a resource.
In this lecture we will see how a URL is constructed and why we need URL encoding.
Before we move on, I want to clarify what a URL is and the differences between a URL and a domain name.
URLs understand Hexadecimal values.
But what exactly is hex?
At its most basic level, it's just a numeric counting system. Hex is a base-16 number system, which consists of 16 unique symbols. Hexadecimal uses all 10 numbers in the decimal system (0, 1, 2, 3, 4, 5, 6, 7, 8, and 9) and letters A through F.
For example, "computer hope" in hexadecimal becomes "636f6d707574657220686f7065".
Anyone who has designed a web page has encountered hexadecimal value when doing colors. For example, to create red text use the HTML color code #FF0000, which translates to 255 red, 0 green, and 0 blue in hexadecimal.
When working with large digital systems, such as computers, it is common to find binary numbers consisting of 8, 16 and even 32 digits!
This makes it not only difficult to read, but also difficult to write.
One common way of overcoming this problem is to arrange the binary numbers into groups or sets of four bits (4-bits). These groups of 4-bits uses another type of numbering system also commonly used in computer and digital systems called Hexadecimal Numbers.
URLs have to abide by certain rules, and these rules say that a URL needs to be composed from a limited set of characters belonging to the US-ASCII character set. These characters include digits (0-9), letters(A-Z, a-z), and a few special characters ("-", ".", "_", "~").
This means that any weird characters (like a backspace, vertical tab, horizontal tab, line feed etc), unsafe characters like space, \, <, >, {, } etc, and any character outside the ASCII charset is not allowed to be placed directly within URLs.
So what do we do when we need to transmit any data in the URL that contain these disallowed characters? Well, we encode them!
You've learnt a lot over a short space of time, so its now time to take a step back and recap what we've learnt about URL encoding and why we can see international characters in the address bar of most browsers.
We have the RFC 3987 document that defines an IRI. However, this document only applies to international characters that are found within the path section of the URL. Few developers know this.
This lecture is long.
Brace yourself, enjoy and stick with me.
It can be very confusing when it comes to understanding how encoding works and the different rules that apply depending on what spec is governing the current URI.
That's why I've put together this short article, to help you become a master at this.
Sometimes you'll see a space being converted to %20, and other times to a +.
The question is why?
That's what this lecture is all about.
The encodeURIComponent() function encodes part of your URI into a UTF-8 representation. This lecture shows you an example.
Let me clarify what and why we use the encodeURIComponent() method.
Save
Instructor's explanations are clear and knowledgeable.
Practical exercises reinforce learning effectively.
Course excels at explaining underlying concepts.
OpenCourser helps millions of learners each year. People visit us to learn workspace skills, ace their exams, and nurture their curiosity.
Our extensive catalog contains over 50,000 courses and twice as many books. Browse by search, by topic, or even by career interests. We'll match you to the right resources quickly.
Find this site helpful? Tell a friend about us.
We're supported by our community of learners. When you purchase or subscribe to courses and programs or purchase books, we may earn a commission from our partners.
Your purchases help us maintain our catalog and keep our servers humming without ads.
Thank you for supporting OpenCourser.
