This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
The content model of <datalist> is described thusly: “Either: phrasing content. Or: Zero or more option elements.” This clearly says that <datalist>foo</datalist> is OK and so is <datalist><option></datalist> but <datalist>foo<option></datalist> is not (because it’s either or). Yet, the prose text says: “The contents of the element represents fallback content for legacy user agents, intermixed with option elements”. And http://validator.nu plays by this principle; it accepts <datalist>foo<option></datalist>. A minimal fix would be to change the content model description to “Phrasing content and option elements” but perhaps the following more formal description is needed instead: “Phrasing content optionally intermixed with option elements”. This content model implies that any option element should be explicitly closed with a closing tag, e.g. <option value=foo></option>, if it is followed by phrasing content. Otherwise the phrasing content will be parsed as option element content, possibly causing a syntax error.
The content model is right, but you're right that I should make it clearer what's going on. The idea is that if you want to do fallback, you do it with a <select> element inside the <datalist> element. I'll add an example or something.
(In reply to comment #1) > The content model is right So is the validator wrong? And the prose text? It says: “The contents of the element represents fallback content for legacy user agents, intermixed with option elements that represent the predefined options.” I don’t see how this could be possible if the content model, with “or” at top level, is right. > The idea is that if you want to do fallback, you do it with a <select> > element inside the <datalist> element. I'll add an example or something. An example or two would help indeed. My intuitive understanding was that since <datalist> is something associated with a control, feeding predefined alternatives into it, the natural content would be descriptive prose, possibly mentioning some examples as alternatives, e.g. as in <label for="dest">Destination city:</label> <input name="dest" list="cities"> <datalist id="cities"> <br>(Enter city name, e.g. Helsinki, Espoo, or Turku.) <option value="Helsinki"> <option value="Espoo"> <option value="Turku"> </datalist> If the content model is right, this is not allowed. I don’t see how using <select> elements would help. On old browsers, <select> would create a dropdown menu, so there would be a text field *and* a dropdown, for the same data. Do you mean that the approach would be something like the following: <label for="dest">Destination city:</label> <input name="dest" list="cities"> <datalist id="cities"> <br>(Type a city name in the bow above or select it from the list below:)</br> <select name="dest"> <option value="Helsinki"> <option value="Espoo"> <option value="Turku"> <select> </datalist> Then I guess the description should be clarified, saying that the .options IDL attribute returns a collection of all option elements that a descendants of the <datalist> element, not just direct children. Note that the current wording for datalist.options says “Returns an HTMLCollection of the options elements of the table”, where “table” must be a slip; the sentence should probably end with “the option elements inside the datalist element” (corresponding to the more formal text after the statement).
I've tried to clarify the spec. Thanks for the feedback!
Checked in as WHATWG revision r7993. Check-in comment: Clarify <datalist> content model. http://html5.org/tools/web-apps-tracker?from=7992&to=7993