[whatwg] <datalist> and invalid values

I tend to agree with Jonas on the performance (or load time) aspects of
this. If we had multiple such lists each with a large number of items it
could cause serious performance issues.

And what does the spec say about dynamically loaded items. Is the UA going
to go through the validation process each time the list of items is
modified?

And are the validation events going to be fired when the UA does it's
validation that first time (supposedly when the page loads) and when the
list of items are added dynamically?

Since the UA is going to do its validation before submitting, why not leave
it to do it at that time?

The recommendations of the spec are akin to swallowing exceptions. Web
developers will be befuddled to say the least.

The use case cited is also fairly common in government scenarios and large
enterprises.

What we're really concerned with is the end values the user fills in before
submitting the form so validation should be done then.

Shiv
http://exposureroom.com


-----Original Message-----
From: whatwg-bounces@lists.whatwg.org
[mailto:whatwg-bounces at lists.whatwg.org] On Behalf Of Jonas Sicking
Sent: Tuesday, September 21, 2010 8:42 PM
To: WHAT Working Group
Subject: [whatwg] <datalist> and invalid values

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

Received on Tuesday, 21 September 2010 22:03:54 UTC