What's the connection between `input` and `datalist`, and do we need to specify `type`?

[jon_morris]

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>
</datalist>

[agentgenx]

@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).

[jon_morris]

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

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

[smallfurrr]

<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?

[jon_morris]

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

[bigboirus]

This was a very clear and helpful explanation! Until I get very comfortable with forms, I think I will continue to always include it.

[hasib033]

In Microsoft Edge, it doesn’t show the text between the option tag. Only shows the value.

[zdrivecode]

Hello jon_morris.
I think your confused as to why we added the type=“text” attribute in the example and not in the practical exercise and what it’s purpose is? right?

So fist let me adresse this by understanding what is sent as a “request” to the “server”.
If no text attribute is mentioned as in:

<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="Ranch"></option>
          </datalist>

the POST request will send to the “server” an answer from the drop down options in a pair [name = value]
the “name” part in this example is always “sauce” and has access to the data list variables through a hierarchy of 1 intermediate variable called “sauces”

If you put a text attribute like this code:

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

  <datalist id="cities">
    <option value="New York City"></option>
    <option value="Tokyo"></option>
    <option value="Barcelona"></option>
    <option value="Mexico City"></option>
    <option value="Melbourne"></option>
    <option value="Other"></option>  
  </datalist>
</form>

The POST request can either send a pair [name = value ] from the datalist values (Mayo,Ketchup,…) or a custom “request” with wathever is typed in the text box and “Submitted” in the format [ name = value ] with the value being the text submitted in the text box.

Hope this helps!

[jon_morris]

Hey @py5351253411,

Now that is interesting! So, are you saying that if we don’t include  type="text"  in the <input> element, the option of inputting our own custom request is not available i.e. we’d be forced to select one of the set options from the datalist?

I’m interested in getting to the bottom of this, because after the original discussion (well over a year ago) my understanding was that if  type="text"  was excluded then the input field would still default to text input. However, would omitting it only allow custom text input when there is no associated datalist? i.e. if we want custom text input in addition to set options from a datalist, we have to include  type="text"…?

When I have some time, I’ll try testing this.

Thanks for your input

[digital2728968217]

@jon_morris

Use of the type attribute when creating a datalist input is made even more confusing in exercise 14

I am new learner but i guess type attribute gives you an option to submit your typed value if it is not available in the given datalist. Correct me! if i am wrong.