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

[Ian Hickson]

On Fri, 29 Jul 2011, Jonas Sicking wrote:
> 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.
> >>
> >> Couldn't this be accomplished using a few lines of javascript?
> >
> > 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 extremely 
> small.

That's possible. The entire Web Forms 2 feature set is designed with this 
kind of fallback in mind, though.


> 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 it, 
> and then use javascript as a fallback and not care about users with JS 
> disabled. And that goes even if we add this feature or not.

If that's the case, we should probably rethink the entire design of the 
WF2 features, because maybe there's better ways to do things.

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.


> >> 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.

It's not the reason to add the feature. I'm just saying that browser 
complexity in this case isn't a reason to _remove_ the feature.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'