W3C home > Mailing lists > Public > public-html@w3.org > January 2012

[Bug 15645] New: Problem: Changing the state of a <select multiple> element from *contains one or more selected options* to *contains zero remaining selected options* doesn't communicate the change of state to the form processor since the select element is changed to "emp

From: <bugzilla@jessica.w3.org>
Date: Fri, 20 Jan 2012 16:30:34 +0000
To: public-html@w3.org
Message-ID: <bug-15645-2495@http.www.w3.org/Bugs/Public/>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=15645

           Summary: Problem: Changing the state of a <select multiple>
                    element from *contains one or more selected options*
                    to *contains zero remaining selected options* doesn't
                    communicate the change of state to the form processor
                    since the select element is changed to "emp
           Product: HTML WG
           Version: unspecified
          Platform: Other
               URL: http://www.whatwg.org/specs/web-apps/current-work/#top
        OS/Version: other
            Status: NEW
          Severity: normal
          Priority: P3
         Component: HTML5 spec (editor: Ian Hickson)
        AssignedTo: ian@hixie.ch
        ReportedBy: contributor@whatwg.org
         QAContact: public-html-bugzilla@w3.org
                CC: mike@w3.org, public-html-wg-issue-tracking@w3.org,
                    public-html@w3.org


Specification: http://dev.w3.org/html5/spec/Overview.html
Multipage: http://www.whatwg.org/C#top
Complete: http://www.whatwg.org/c#top

Comment:
Problem: Changing the state of a <select multiple> element from *contains one
or more selected options* to *contains zero remaining selected options*
doesn't communicate the change of state to the form processor since the select
element is changed to "empty" and as such the select element is no longer a
[successful
control](http://www.w3.org/TR/html4/interact/forms.html#successful-controls).

The state of the select element has *changed* but it has changed to contain
zero selected options. This should be a valid state to be submitted to the
server for processing as it affects the state of the form's data model's
attribute which is controlled by the select element. But it seems as though
this is not the implemented expectation which user-agents currently employ.

Are user-agents correctly implementing the HTML specification, are they
implementing it incorrectly, or is the specification ambiguous leaving room
for error? It feels to me like a case of ambiguity perhaps.

[The HTML5
spec](http://dev.w3.org/html5/spec/Overview.html#the-select-element) says that
a multiple select element "represents a control for selecting zero or more
options from the list of options", but does the meaning of "selecting zero
options" mean simply that the user can **optionally select something** (i.e.,
that given a list of options that are all *not* selected, the user can choose
not to select anything, effectively submitting the containing form with no
change to the select element's options selectedness) or that a user can
**express the value of zero** (i.e., that given a list of options, some of
whose selectedness is true, if a user sets *all* options' selectedness to
false, this should communicate a subtly different event that is a state of
*newly empty* to the form processor).

--

Forgive me if this is a naive question. I could very well be missing a key
point, in which case I apologize for using up your time. But if this is indeed
an ambiguity in the spec, I hope this particular issue could be more clearly
expressed in the spec. Thanks.

I've expressed additional detail here if it helps:
http://robmclarty.com/blog/html-multiple-select-element-doesnt-express-the-sta
te-of-newly-empty/

Posted from: 76.65.209.5
User agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_5_8) AppleWebKit/535.7
(KHTML, like Gecko) Chrome/16.0.912.75 Safari/535.7

-- 
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
Received on Tuesday, 24 January 2012 01:03:19 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:17:43 GMT