W3C home > Mailing lists > Public > public-html-bugzilla@w3.org > September 2010

[Bug 10911] New: Datalist descendants shouldn't be barred from constraint validation

From: <bugzilla@jessica.w3.org>
Date: Thu, 30 Sep 2010 22:19:59 +0000
To: public-html-bugzilla@w3.org
Message-ID: <bug-10911-2486@http.www.w3.org/Bugs/Public/>

           Summary: Datalist descendants shouldn't be barred from
                    constraint validation
           Product: HTML WG
           Version: unspecified
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: HTML WG website
        AssignedTo: dave.null@w3.org
        ReportedBy: mounir.lamouri@gmail.com
         QAContact: public-html-bugzilla@w3.org
                CC: mjs@apple.com, Paul.Cotton@microsoft.com,
                    rubys@intertwingly.net, mike@w3.org

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.

There is this backward-compatibility friendly use of datalist that requires to
have a select inside a datalist like:
<input list='d'>
<datalist id='d'>

However, this use case doesn't justify barring from constraint validation
because the only situation where that would be needed is if <select> is
required and the first option is making select suffering from value missing.
However, using required in a backward-compatibility path would be wrong and
using required wouldn't follow how lists are working (ie. you don't _have_ to
select something).

Is there any other reasons I'm missing?

Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
Received on Thursday, 30 September 2010 22:20:00 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:26 UTC