The next attribute I want us to talk about is the "name" attribute. And remember, we are dealing with...
form attributes here, only the <form> itself.
So the name attribute could look something like this.
That's right.
We can assign the value of myCoolForm to the name attribute. As you probably would expect, the name attribute...
names your form. You might be thinking at this point...
"why would I want to name my form? And how is this name any different to using the ID...
attribute? 🤔"
Let me just hop over to the IDE quickly...
let's code up some forms and let me show you the difference.
How can I illustrate what the difference between ID and this name attribute is?
Well, one way is we can obviously code up forms and have a look, and it'll make a whole lot more sense.
So here we go.
I've got a blank file open.
And how can we understand what this "name" does?
Well, the best way is by doing so.
Let's create a form.
Let's get rid of the action, because we don't need it here. But let's create this "name" attribute and as we just called
it in the lecture, why don't we call it myCoolForm.
There we go.
We know that when we start coding up a form 📝, we put all of our widgets within the <form> element tags.
So there we go. That's one form. We can do another form.
In fact, you can have as many as you want.
This can be mySecondCoolForm.
As I said, all of our form widgets, our submit button, etc etc, go in between these <form> tags.
So there we go.
Let's go to the browser...
and let's see what this has done.
Well, actually, before I do that, let me just have an ID here of "a"...
and let's have an ID here of "b", just to be symmetrical. So here we go, we've got a name and we've got an ID on each
form. If we go now to the browser, we see nothing...
and that's what we would expect, because we know the form element does absolutely nothing.
It's only a wrapper, and it only affects things in the background.
We can't visually see it.
"So what does this name attribute do, Clyde?"
OK, well, let me show you. Let's go to the dev Console...
let's just clear it.
Now, let me ask you this question, in order to access a form, how can we do it?
Let's say we wanted to access our first form.
We know our first form has an ID of "a".
How could we do that 🤷🏽?
Well, if you've done my DOM course where we discussed the Document Object Model in detail in frontend...
JavaScript, this will be very, very easy for you.
You could do something like, let's say, hardForm, because this is the hard way to get it. We can access...
our document.getElementById(), and we called...
or, we assigned an id of "a" to that form, right? If we go to the code, we've assigned an id of "a" to our form. And if we return that and
we console.log() our hardForm out, we actually do get our form. But, as the variable name kind-of alludes to...
this is the hard way to do it.
It's the long way.
And this is why we're allowed to have name attributes on a form.
This is why they are there.
If you've done my DOM course, you'll also know that all forms are registered on the document object...
itself.
So all we have to do is access the document. On the document...
we can access our forms. And you'll notice that what's returned to us is an HTMLCollection. Don't worry what an HTMLCollection...
is. Again that's in my DOM course.
For now, just understand it holds a collection of all of our forms.
But can you see something very interesting below?
There are two things I want to point out. Firstly,
our ID's are assigned separate properties, "a" and "b" which relate to each form.
That's the first thing. The second thing is, though, look at what our name attributes have done.
They've created also properties in this collection.
Can you see it?
But what's really cool, is that those properties are registered on the document itself, not only within...
this HTMLCollection! Let me show you what I mean.
So what we can do, is we can access our document.
And if we try and access our form with ID of "a"...
it returns to us undefined. But, if we try and access our name of a form, it will work - myCoolForm. Hit "return" and we...
literally get our form 🥳.
So in other words, there's a much easier way, easyForm...
and that is, document.myCoolForm. The easyForm...
we can just log out now, just to show you that it is actually the same form that we did above.
So there we go.
That's just a very interesting way to access forms.
It's a very easy way to access your form in the DOM.
And I'd say that's the key difference between using ID and giving your form a name attribute.
As you can see, the difference is quite subtle and that's why it's not absolutely necessary.
But that's a cool thing with coding.
Sometimes you want to use it, sometimes you don't.
It just depends on what side of the bed you woke up from this morning 🛏️.
So there we go.
Let's jump back into the lecture.
I really hope that made a lot of sense.
But now, just to throw some bit of confusion into the mix, HTML4 actually got rid of the name...
attribute.
It was deprecated! but we've pretty much done a 360 🔄 because now it's back thanks to HTML5.
And the reason it's back is because sometimes it is lot easier to have this form within that HTMLCollection.
So just remember, the attribute is the name that's used to represent your form in the forms collection...
and that's pretty much it with the name attribute.
You don't have to use it very often.
I don't use it very often.
I don't think many developers do use it very often, but now you're aware of it.
And if you are going to be using the form a lot, then perhaps put it in there.
It's easier to access.
Cool.
So there we go.
I told you, these other attributes are not that difficult. And we've still got a few of them to cover...
so let's keep going.