FAQ: Learn HTML: Forms - Radio Button Input

This community-built FAQ covers the “Radio Button Input” exercise from the lesson “Learn HTML: Forms”.

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

Introduction to HTML

FAQs on the exercise Radio Button Input

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!

2 posts were split to a new topic: Why do we put yes in the value and in the label?

6 posts were split to a new topic: Can name, value, and id be the same? Should they be?

2 posts were split to a new topic: How do I differentiate radio buttons?

2 posts were split to a new topic: How can I set a default value for radio buttons?

A post was split to a new topic: Wierd typo in html forms?

Is there any standardized order to add the “id” “type” “name” and “value” attributes inside an input tag? If not, what would be the best way to keep these elements to avoid making mistakes and improve ease or reading?

Hey Damian,

There isn’t. The key, in my humble opinion, is consistency:

1 Like

Why do we use radio buttons when we can create the same thing just using type checkbox?
I don’t see how radio buttons are necessary

Check boxes are independent and can have more than one checked in a group. Radio buttons in the same group (having the same name attribute) can only have one item selected.

2 Likes

Thank you, I guess I would become more organized and consistent as a i grow my experience

If more is less, why do we keep assigning and id to every input type. I understand they may come in handy when incorporation CSS into it, but won’t we have extraneous code all over the place with elements we might not ever touch in CSS? Also, won’t we start running out of id names if code gets dense enough?

Thank you.

Yes, and no. We can traverse a form without any fragment identifiers. Same applies to script. However, it takes time and effort to design it so most authors will go with what’s simplest.

Take the <label/> element, for instance. We can have a freestanding label (opened and closed) anywhere in the form markup and give it a for attribute and a screen reader or user agent will immediately associate it with the form control having a matching id attribute.

<label for="item">Item </label>
<input id="item" placeholder="Your item">
<input id="todo" placeholder="Your to-do">
<label for="todo"> To-Do</label>

We can rid our markup of both attributes simply by nesting the <input> within the <label/>.

<label>Item 
  <input placeholder="Your item">
</label>
<label>
  <input placeholder="Your to-do">
To-Do</label>

css

body {
  font-size: 100%;
}
label {
  display: block;
  height: 1em;
  padding: 0.3em;
}
label:hover {
  background-color: #fdfeff;
  border: 1px solid #ccc;
}

form labels without id and for - Replit

I feel it’s not so clear on why and how Radio Button only allows the user to choose only one choice among the provided options, so I looked it up a bit…

Basically the key is to group the Radio Buttons together under the same “name” attribute group, so that only one choice under the same “name” attribute group can be chosen without overlapping.

On the other hand, if you put each Radio Button under their own unique “name” attribute group, all of the options can be selected without problems, but that’s not the intention here. So be careful when giving “name” attribute in a Radio Button input. If one wants to have multiple groups of Radio Buttons, they can just give different “name” attribute group to group each Radio Button group and that would work.

More detail: Mozilla Web Docs - radio groups

Hope that helps!

Would you like to add cheese?
Yes No
  </form>
</section>

do you guys know why we should use (name=“cheese”) in this exercise , is it not spouse to be (cheesy) because of this
why in the exercise says that we have to call name attribute (cheese) instead of cheesy.
i appreciate if anyone can explain.

1 Like

Why, when we include the radio buttons in this exercise, the checkboxes appear to the right of the label, but when we move on to the next exercise, the checkboxes appear to the left of the label, even with the same code?
The same happens in the checkbox input exercise.
I upolad the screenshot of the Radio Button exercise, indicating with red arrows what I mentioned.

It depends which order they are written in the markup. HTML is parsed and rendered top down.

Thanks.
Really, the label must come before the input form.

It is up to the author to choose where to place the label. The is no, ‘must’ involved. For accessibility (WCAG) the guideline is that input fields each have a descriptive label. There is no mention of placement.

The thing to understand about labels is that clicking them will give focus to their for input. We don’t just have to click the checkbox (or other input control). We can also click the label with the same effect.

Apologies if this has already been addressed here (or will be within the course). Is there a way to allow users to un-check a radio button? What would this look like?