[whatwg] Why children of datalist elements are barred from constraint validation?
jonas at sicking.cc
Fri Jul 29 08:39:01 PDT 2011
On Thu, Jul 28, 2011 at 6:07 PM, Ian Hickson <ian at hixie.ch> wrote:
> On Mon, 2 May 2011, Jonas Sicking wrote:
>> On Mon, May 2, 2011 at 3:36 PM, Ian Hickson <ian at hixie.ch> wrote:
>> > <select> in a <datalist> is completely ignored for form submission. In
>> > fact, any form element at all in <datalist> is ignored for form
>> > submission. See the "construct the form data set" algorithm:
>> > http://www.whatwg.org/specs/web-apps/current-work/complete.html#constructing-the-form-data-set
>> > It's so that you can do things like:
>> > <input ... list=options>
>> > <datalist id=options>
>> > <select ...>
>> > <option>...</option>
>> > </select>
>> > ...maybe other form controls here...
>> > </datalist>
>> > Basically everything in the <datalist> except the <option> elements is
>> > for fallback in legacy UAs and is ignored in new UAs.
> Not when scripts are disabled, no.
The number of cases when a site can use this solution to get an
acceptable UI *and* care about supporting users with scripts disabled
*and* is planning to roll out support within the timeframe when
there's some support for HTML5 forms, but not enough to rely on it, is
My experience is that it's much more likely that people will use other
solutions until there is wide enough browser support to reliably use
with JS disabled. And that goes even if we add this feature or not.
>> That seems like a better solution than one that for all eternity adds
>> browser code complexity both to do a deep search for <option> elements
>> when building the list for <datalist>, and that requires walking the
>> parent chain whenever submitting form controls.
> It doesn't seem that bad. Surely code for both of those is so widely used
> in a browser that both of those operations are basically one-liners.
"It's easy to implement" is the worst reason ever to add a feature.
More information about the whatwg