[whatwg] <datalist> and invalid values

[Jonas Sicking]

Hi All,

Currently the spec says that if an <input> has a list attribute
pointing to a <datalist>, and that <datalist> has an <option> with a
value which is not a valid value for the <input>, then that <option>
should be included in the list of suggestions made by the UA. The
relevant text in the spec is:

"User agents must filter the suggestions to hide suggestions that the
user would not be allowed to enter as the input  element's value, and
should filter the suggestions to hide suggestions that would cause the
element to not satisfy its constraints."

I'm curious why this wording exists in the spec. I see several problems with it:

1. It adds extra complexity to implementations
2. If the <datalist> contains many options, it can be a performance
problem, for example putting a list of all company email addresses. I
imagine this might not be rare since it's likely to produce decent UI
even, for a very large number of <option>s. This is especially the
case if the <input> contains a pattern attribute, for example to
enforce that only company email addresses are used.
3. If the page author has specifically put an <option> in the list,
why do we think we "know better" and hide it? I assume we suspect that
the author must have had a bug in the code that generated the list of
<option>s, but I struggle to think of what type of bug we are
concerned about.

On the other hand, I can think of at least one use case when the
author would *want* to display suggestions even though they don't
match the <input> elements constraints. Consider for example:

<input type=tel pattern="\d\d\d-\d\d\d-\d\d\d\d" list="prefixes">
<datalist id=prefixes>
  <option value="650-">
  <option value="415-">
</datalist>

This would be appropriate for a company that does business in the San
Francisco area. It helps the user enter phone numbers with common
prefixes, while allowing the user to enter any US phone number. This
method can be used any time there is a common, or even required, set
of prefixes that the user is expected to enter.

While prefixes might not be common, it seems strictly easier and more
performant, even in the common case, from an implementation point of
view to allow it.

/ Jonas