Codecademy Forums

FAQ: Learn HTML: Forms - Datalist Input

This community-built FAQ covers the “Datalist 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 Datalist Input

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!

Why don’t we use text between the opening and closing tags here, like we did in the dropdown menu?


In the Learn section of this exercise it says:

The <datalist> is used with an <input type="text"> element.

It seems that the logic to this is explained as being because this:

… creates a text field that users can type into and filter options from the <datalist>.

Indeed, in the example that’s then given, the <input> element includes this type="text" attribute, along with 3 other attributes, as follows:

<label for="city">Ideal city to visit?</label>
<input type="text" list="cities" id="city" name="city">

However, in the code given in this exercise’s code editor, the type="text" attribute is excluded altogether, as follows:

<label for="sauce">What type of sauce would you like?</label>
<input list="sauces" id="sauce" name="sauce">

The code seems to give the same result with or without type="text". Is it therefore optional, or even redundant?

Use of the type attribute when creating a datalist input is made even more confusing in exercise 14 - Forms Review, where it says:

Setting type to "list" will pair the <input> with a <datalist> element.

Am I right in thinking that this is actually wrong, because type is either set to "text" or excluded altogether? i.e. it can’t have a value of "list" because list is an attribute in its own right and set to the same "value" as the <datalist>'s id attribute? This is what is suggested by the code given to us in the code editor in exercises 12, 13 and 14, as follows:

<label for="sauce">What type of sauce would you like?</label>
<input list="sauces" id="sauce" name="sauce">
<datalist id="sauces">
  <option value="ketchup"></option>
  <option value="mayo"></option>
  <option value="mustard"></option>

In this exercise, when I typed in the datalist lines, the screen became an automatic roll down. Is this a CSS feature ?

<input list="sauces" id="sauce" name="sauce">
<datalist id="sauces">

Why is the id for the datalist “sauces” and not the stated id of “sauce”, as was the case in the previous exercises? What role does id=sauce play here?

The way I understood it is as follows:

The label is linked to the input field via the value "sauce", which is assigned to the <label>'s for attribute and the <input>'s id attribute. This is the same method used with other previous input fields.

The <datalist> is then linked to the input field via the value "sauces", which is assigned to the <datalist>'s id attribute and the <input>'s list attribute.
<input> already has an id of "sauce" and from what I understand the same id value should only be assigned to one element, so <datalist> needs a different id. Using a plural creates a different id yet still indicates the relationship (although any other word could be used).

Also, notice that with the dropdown menu we don’t have this issue as, instead of an <input> element, we have a <select> element which is wrapped around all the fixed options (and creates the actual dropdown).
<select> is linked directly to the label without any need for an input field.

With the datalist, however, we have to accomodate for both a manual ‘free-choice’ input field and a list of pre-selected prompts. We do this by using <input> and <datalist> respectively.

There may be some deeper theory here, but I’m just a beginner. This is how I rationalised it - I hope it helps :smile:


After struggling to figure out why the element wasn’t working right for me in this lesson, I finally discovered that the safari web browser does not support that specific element. Thought I would share in case others having the same frustration.


@jon_morris, I believe that you are correct, in that what you saw in the exercise 14 review:

Setting type to "list" will pair the <input> with a <datalist> element.

…is incorrect.

I’m not there yet, I’m on exercise 11, and it clearly says:

in the code above, we have an <input> that has a list attribute. The <input> is associated to the <datalist> via the <input> 's list attribute and the id of the <datalist> .

I researched it a bit, and <list> is definitely not listed as a form <input> type per Mozilla’s documentation.

Mozilla’s docs may have also answered another of your questions (and one I was wondering too). Regarding the <input> tag’s <type> attribute:

If this attribute is not specified, the default type adopted is text .

Maybe that’s why Codecademy didn’t include it, and why it still worked - the value defaulted to ‘text’.

When I get to the exercise 14 review, I’ll submit a bug to have it checked out, if it hasn’t already been done (for the setting the type=“list” reference).


@jackolien This is just a beginner’s guess, but I think it’s excluded because if we add the in-between text, then the word is rendered twice on the list - it also shows the value, so I ended up with “ketchup … Ketchup”, “mayo … Mayo”, etc. when I added in the text to see what happens. Unfortunately that leaves us with uncapitalized words in the list…maybe CSS could alter that? I’m not that far yet :relaxed:

EDIT: Looking over the exercise again, in the left/instructions pane Codecademy capitalized their values in the datalist example, I wasn’t aware we were allowed to do that, but that fixes the list items being capitalized.

1 Like

Thanks for this @agentgenx! That helpfully confirms what I had assumed about list being a separate <input> attribute associated with the <datalist>'s id, and not a value of type.

And very good to know about the type default being "text", as that definitely clears up the confusion over its appearance then disappearance :smiley:

I didn’t submit an error report for the exercise 14 review, as I thought it was better to raise it as a query here first. So, now we’re certain, go ahead and do that yourself when you get there :+1:

1 Like

Gosh, thank you!! I was wracking my brain wondering why it wasn’t working.


Is the option tag a self-closing tag?

Start tag: required , End tag: optional

That is for HTML 4, so one can assume it is still the case with HTML5. However, when the stricter XML compliance rules apply, it may not be the case.

HTML can be served as text/html or as application-x/xml, the latter adhering to the stricter spec.

Going through the HTML5 docs I’m still looking for clarification…

The screenshot shows that I had a different output with the datalist than shown in the lesson text: for me, the HTML values appeared to the user! In the left of the screenshot it shows what it is supposed to be (what the lesson text shows), and in the right of the screenshot it shows how it actually rendered, with both the values and the text that was supposed to be shown. Is this normal? Does the codecademy lesson text image need to be updated? The previous form types shown to us did not have the value appear to the user (e.g. with the checkbox lesson).



The understanding of all the elements of the course is going amazingly well, but one thing won’t connect in my brain: the difference between id and name? Is there a very clear explanation for this difference and wht use them both in one ?

id is mostly used in javascript or for binding labels to stuff. For example:

<input type="text" id="foo"/>
<label for="foo">bar</label>

or a javascript example:


The name attribute i have only seen used for the radio type for options.
in this case the name makes sure the radio buttons are grouped to each other. for example:

  <input type="radio" id="huey" name="drone" value="huey"
  <label for="huey">Huey</label>

  <input type="radio" id="dewey" name="drone" value="dewey">
  <label for="dewey">Dewey</label>

  <input type="radio" id="louie" name="drone" value="louie">
  <label for="louie">Louie</label>

As can be seen all options are grouped under the name “drone” which makes sure only one radio button can be selected.

Not sure if name is used in any other way by default. But since name is just an attribute you could also use it with javascript. It would act similar to a class attribute i believe.

Thanks. Name for grouping in something like radio buttons makes sense. I’ll let it go through my brain :wink: I will remember your help when I’m months in this Web Devloper career path and need to use it!

If I’ve this piece of code I’m currently working on as part of the course. Why do I always have id and name?

 <form action="story.html" method="get">
        <label for="animal-1">Animal:</label>
        <input id="animal-1" type="text" name="animal-1" required>
        <label for="animal-2">Another Animal:</label>
        <input id="animal-2" name="animal-2" type="text" required>
        <label for="animal-3">One More Animal:</label>
        <input id="animal-3" name="animal-3" type="text" required>
        <label for="adj-1">Adjective (past tense):</label>
        <input id="adj-1" name="adj-1" type="text" required>
        <input type="submit" value="Form My Story!">

The id is binding to the for in the label. The name is captured by Submit and paired up with the input in the POSTDATA.

1 Like

This is makes it clear to me! Thanks

1 Like