[whatwg] Why children of datalist elements are barred from constraint validation?

[Jonas Sicking]

On Tue, Aug 2, 2011 at 1:30 AM, Henri Sivonen <hsivonen at iki.fi> wrote:
> On Fri, 2011-07-29 at 15:20 -0700, Jonas Sicking wrote:
>> On Fri, Jul 29, 2011 at 2:59 PM, Aryeh Gregor <Simetrical+w3c at gmail.com> wrote:
>> > On Fri, Jul 29, 2011 at 5:51 PM, Jonas Sicking <jonas at sicking.cc> wrote:
>> >> On Fri, Jul 29, 2011 at 9:43 AM, Ian Hickson <ian at hixie.ch> wrote:
>> >>> Looking specifically at <datagrid>'s ability to fall back to <select>, I
>> >>> agree that it's not necessarily doing to be widely used, but given that
>> >>> it's so simple to support and provides such a clean way to do fallback, I
>> >>> really don't see the harm in supporting it.
>> >>
>> >> I haven't looked at <datagrid> yet, so I can't comment.
>> >
>> > I think he meant <datalist>.  <datagrid> was axed quite some time ago
>> > and hasn't made a reappearance that I know of.
>>
>> Ah, well, then it definitely seems like we should get rid of this
>> feature. The harm is definitely there in that it's adding a feature
>> without solving any problem.
>
> The current design solves the problem that the <datalist> feature needs
> to Degrade Gracefully (and preferably without having to import a script
> library). I think the solution is quite elegant and don't see a need to
> drop it.

What's the purpose of a degrading mechanism if it produces a result
which is ugly enough that sites will not want to use it? It's not a
goal in and of itself to have a fallback mechanism. The goal is
helping sites deploy the feature.

Looking at it some more, the example in Jeremy's blog post does in
fact not work that well since it adds "please choose..." and "Other"
as suggestions when the <datalist> is supported. This is likely not
acceptable for websites.

<video> and <canvas> provide good data points. Both have fallback
mechanisms which are supposed to work without script. Yet in the far
most common case people don't use these fallback mechanisms since they
don't result in a rendering which lives up to their requirements.
Instead they use script based feature detection and deal with lack of
support by generating a wholly different DOM.

I'd be very curious to know what percentage of sites that use <video>
or <canvas> support non-scripted fallback mechanism with a useable
result.

<frameset> is another good example where the far most common use of
the fallback mechanism was to deliver the wholly unhelpful "Your
browser doesn't support frames" message.

I talked this over with Mounir some more. The current design of
wanting fallback for <datalist> results in three behavioral
requirements:

1. Elements inside a <datalist> are not supposed to be submitted
2. Elements inside a <datalist> are not supposed to be subject to
constraint validation
3. When looking for <options> the search is recursive rather than just
looking at direct children of the <datalist>

It's not clear what problem 1 solves. It's easy for sites to ignore
the value submitted for the <select> if the contents of the <input> is
non-empty. Same thing with 2, it's easy to create fallback which works
in all browsers by simply not adding any constraint requirements.

3 does indeed provide some value in theory, though I'm still very
skeptical that anyone will use it and thus it will just be feature
bloat. Especially since I have yet to see a decent example of good UI
that can be created with it. It is however the easiest one to
implement at least in Gecko since we have a simple switch which allows
to choose between a deep or a shallow search. But as I've stated
before, ease of implementation is not a good reason to add a feature.

It seems to me that if we looked at any other feature with this small
set of sites that we expect to use it (sites that are ok with
imperfect rendering and which target browsers with javascript turned
off), and for such a short period of time (only until <datalist> is
supported in all major browsers) we would not add such a feature.

I'm all for having a sensible upgrade path, but I think we have that
anyway, which is simply that users will have to type the value.

/ Jonas