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

[Jonas Sicking]

On Mon, May 2, 2011 at 3:36 PM, Ian Hickson <ian at hixie.ch> wrote:
> On Fri, 31 Dec 2010, Mounir Lamouri wrote:
>> On 12/31/2010 03:20 AM, Ian Hickson wrote:
>> > On Fri, 24 Sep 2010, Mounir Lamouri wrote:
>> >>
>> >> I agree that a child of a datalist element should not block the form
>> >> submission. However, I'm wondering why do we care about this
>> >> particular edge case when there are a lot of situations where an
>> >> element can be invalid without any possible action from the user.
>> >>
>> >> If there is no specific use cases in mind I think we should just
>> >> remove that.
>> >
>> > It's so that you can use a <select> in the <datalist> (with the same
>> > <option>s) for fallback in older UAs, without that <select> having any
>> > effect on the form submission.
>>
>> I do not understand that the <select> inside the <datalist> should not
>> be invalid but why it *has* to be barred from constraint validation?
>> Adding the required attribute to the select element in that case would
>> be stupid and useless. The other way to make the <select> element
>> invalid would be by calling .setCustomValidity(). Is there a real use
>> case that require calling .setCustomValidity() in batch? Even if, can't
>> we rely on the authors not calling .setCustomValidity() on elements that
>> should not be invalid? We already do that for non-displayed elements,
>> don't we?
>>
>> You should take into account that this requirement force the UA to check
>> the entire parent tree to prevent a situation that can happen in various
>> other ways.
>
> <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? 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.

/ Jonas