Welcome back, my dear students.
Hope you're having fun.
I just wanted to take this time and thank you for supporting me.
Thank you for sticking with me.
I know it can seem quite daunting.
We literally are covering a ton of information, but trust me, it's going to help you in your web development
career and you will be dealing with forms a lot.
That is something we can't avoid.
So stick with me, continue to stick with me and we'll get through it together.
Anyway, I just thought I'd take this lecture to discuss some of the common attributes that we'll see
on most form widgets.
So most of the elements used to define form controls have some of their own specific attributes.
However, there is a set of attributes common to pretty much all form elements.
We've seen a lot of these already in the course, but for your reference, I just thought, let me have
one lecture where I discuss the common attributes that you'll see. So, we can see we've got disabled, autofocus
form, name and value.
Let me discuss each one.
First, let's look at disabled.
It's an attribute and that's how it looks, right?
We just put it within the input element.
And why would we want to put this on?
Well, disabled inputs do not receive the click event and disabled inputs are not submitted with the
form to the server.
So it basically makes all inputs, textareas and fieldsets or descendants of them non-editable and
unclickable.
Another thing I want to actually say here is that what's interesting is that a disabled field can't
be modified, tabbed to, highlighted or have its contents copied, right. And obviously its value is going to
be ignored when the form goes through constraint validation.
As you can see on the example on the screen, it is a boolean value.
It's either there or it's not.
So you don't need to assign it a value.
What's interesting is that setting it to null does not remove it.
It's still going to be there.
And as I mentioned, the element will inherit this setting from its parent.
So if you put the disabled attribute on a form, its elements within it will inherit that property.
And of course the default value is false.
Or another way of saying it, is by default that disabled attribute is not there.
Cool.
So those are the main points about disabled,
but I do have a few more, and I thought I'll put them in a light bulb ðŸ’¡ just to break things up.
Did you know that setting the value of disabled to null does not remove the control.
Yes.
You do know that because I mentioned that a few seconds ago.
The other interesting thing is we can target elements that are disabled with the :disabled pseudo class.
Similarly, we can target elements that are enabled with the :enabled pseudo class, or we can even use
the new CSS, "not" keyword.
So, input:not([disabled]). And we can use the disabled attribute on most form controls such as all input
types, textarea, buttons, select, fieldsets and keygen [elements].
So it's widely in use.
That's exactly why I want you to know about it.
All right.
So that's disabled.
Next, I want to talk about the autofocus attribute.
How does that look?
Well, here I've just applied it to an input of type text.
What does it do?
It lets you specify that the element should automatically have focus when the page loads.
What about if you have it on more than one element, which one will get focus?
Well, it depends.
Originally in the specification, the last element with the autofocus attribute received the focus.
Safari still does this, but Internet Explorer, Firefox, Chrome, Opera,
they all focus on the first occurrence of the attribute.
And if you do want to use a fallback or a polyfill, for example, just in case a browser doesn't support
this, make sure to fire it on the DOM Ready Event [aka: DOMContentLoaded] rather than the window.onload event, because it's
going to be jarring to have the page position jump after
the user may already be interacting with the page.
So try not to use the onload event.
So that's the autofocus.
Should you use it?
Well, I've got a bomb ðŸ’£ there and the reason for the bomb is I want you to beware when using this.
The AutoFocus forces a page scroll and it can get quite annoying.
It can also confuse visually impaired people and screen readers, and it can also cause dynamic keyboards
to display on some touch devices.
While a screen reader will announce the label of the form control receiving focus,
the screen reader will not announce anything before the label, and a sighted user on a small device
will equally miss the context created by the preceding content.
So to cut a long story short, it's probably good that mobile WebKit doesn't support the autofocus attribute
as the zooming keyboard opening would be far too much in your face in most circumstances, and even
more than this, MDN advises against using it altogether.
So for those reasons, try and avoid it, please.
Next, I want to talk about this form attribute.
We've actually already seen the form attribute.
We've used it a few times in a few examples. And that's an example, where you just put it on an element,
you use the form attribute and remember you have to match it to the actual main form ID you want it to
relate to.
And previously, and by previously I just mean HTML4, they or that spec insisted that all form widgets
were contained in one form block.
But now we know by using the form attribute, we can associate a widget with a form, even if it's not
within the main form.
But remember, the value of that form attribute in the widget must be equal to the form
ID. Remember, we looked at an example of this ages ago where we had the form split up between the top
of the page and the bottom of the page, and we submitted the form and we could see that all the widgets
data was submitted with that main form.
So it can be quite useful.
The next one is super, super important and that is this value attribute, right. Here, with type checkbox,
we set its value to accept. When specified in HTML, the value attribute specifies the initial value,
but it doesn't have to stay like that because from then on, it can be altered or retrieved at any time
using JavaScript to access the respective HTML input element
objects value property.
We've seen examples of this numerous times.
Is it compulsory?
Well, yes and no.
The value attribute is optional though should be considered mandatory for checkbox, radio and inputs
of type
hidden. In those instances, the value is crucial.
The next thing I want to mention here is that the value attribute is used differently for different
types of elements, and I guess this is intuitive, right?
For button, reset and submit
for example, it defines the text on the button. For the input element where the type is set to text,
password or hidden,
it defines the initial or default value of the input field. For a checkbox, radio or image
for example, It defines the value associated with the input.
This is also the value that is sent on submit.
But as I mentioned, it's not always mandatory. For the file type,
for example, the value attribute is not valid.
In fact, it's entirely ignored.
So there you go.
That's the value attribute.
And last but not least, this name attribute is very, very important, right?
And that's how we set it, for example, on an input where its type is set to text. And as the name suggests,
it specifies the name for the form control. And you can use the name attribute in many ways.
You can use it to reference elements in JavaScript or to reference the form
data after the form is submitted to a server. And remember the name is submitted along with its value when
the form data is submitted.
So in most instances you should consider the name attribute as a required one.
It's very, very important.
And I've got a few
"did you knows". The name attribute is unique for radio buttons.
What I mean by this is that only one radio button
in a same named group of radio buttons, can be checked at any given time.
So by selecting any radio button in that group, will automatically deselect any currently selected radio
buttons in the same group. And the name of that one checked radio button is sent along with the name
if the form is submitted.
So just remember to create a group of radio buttons
we have the same name attribute, so it kind of plays a very unique role when it comes to radio buttons.
The second thing I want to mention is that the name of an element becomes a property of the owning form
element's HTMLFormElement.elements property!
(sound effect: What do you say?)
What ðŸ˜µ?
"That sounds strange
Clyde". I know, I know.
Let me quickly show you. What do I mean by what I just said?
I know it sounded confusing.
This is all that I mean. Let's set up a very quick HTML document here. And a body. Inside the body,
let's create an input of type text.
And its name can be "guest".
How about that?
Guest.
Okay.
So there is one.
Let's do another one now,
also text.
But here we can go "member".
Okay, let's say we've got these two.
Now, what I want to do is I want to use JavaScript.
I want to grab our form.
You know what?
Sorry, I forgot to have the form here.
There we go.
We can give it an ID of mainform.
Take these two inputs and put them in the form ... done.
The first step is I want to grab the form.
So let's define a JavaScript variable using the "let" keyword. We can call it form, and here we can
just document.getElementById(), and we can grab the form.
No.
I mean "mainform".
Sorry.
So there we go.
We've got the form in JavaScript. And now this is what I mean, right.
This is what I mean when I said, when an input element is given a name,
that name becomes a property of the owning form element's
HTMLFormElement.elements
property.
haha ... that is a proper tongue twister.
But this is what I mean.
We can say let guestName be assigned the value of our form.
On our form, we can access the HTML form elements ".elements" property.
So automatically the DOM gives us this ".elements" property and we defined the name as guest.
So we can type guest.
We can do the same with a member.
So let member,
but this time I want to do it differently.
Let's access our form, our ".elements" property.
And now I want to return an object
okay, where the name is member.
And what we can do here is why don't we console.log this out so we can console.log(guestName)
and we can console
log,
console
log member.
Let's now open our browser.
There are the two inputs we just created.
Let's inspect the console.
And there we go.
The first console, of course, is the guest.
Right.
How cool.
And the second one is the member. How awesome is that?
And we just did literally two ways to do exactly the same thing.
If you really want to see something else as well, why don't we just console log quickly ...
let me just go here.
Console log the form ".elements"
property.
Let's see what that does.
Let's go here.
Right.
Let's just clear everything up, refresh the page, and you can see you've got an HTMLFormControlsCollection.
HTMLFormControlsCollection.
Okay.
And if we open up that, you can see both of our inputs are included within this collection.
That's exactly how this code works.
That's why we were able to access our guestName and member.
So there you go.
That's all I meant by that very long tongue twister.
So there you go
my students, these are common attributes that you'll find on just about every input element there is.
And that's why I listed these 5, because these 5 are very, very universal.
Yes, they have slight nuances.
Like name, for example, has a very specific meaning for radio buttons as opposed to its use on a checkbox,
for example.
So these are just very, very good ones for you to know about.
I hope it's making sense.
I hope you're staying motivated and I'll see you soon.