This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 12288 - select.size should be limited to non-negative numbers instead of non-negative numbers greater than zero
Summary: select.size should be limited to non-negative numbers instead of non-negative...
Status: RESOLVED FIXED
Alias: None
Product: HTML WG
Classification: Unclassified
Component: LC1 HTML5 spec (show other bugs)
Version: unspecified
Hardware: All All
: P2 normal
Target Milestone: ---
Assignee: Ian 'Hixie' Hickson
QA Contact: HTML WG Bugzilla archive list
URL:
Whiteboard:
Keywords:
: 12899 (view as bug list)
Depends on:
Blocks:
 
Reported: 2011-03-11 15:18 UTC by Mounir Lamouri
Modified: 2011-08-15 19:34 UTC (History)
8 users (show)

See Also:

Attachments

Description Mounir Lamouri 2011-03-11 15:18:12 UTC 
Gecko has select.size limited to non-negative numbers greater than zero since nearly 10 months now but we recently got three bug reports that let us think this change wasn't web compatible.

Currently, select.size works this way for other vendors:
- no limitation: Firefox 3.6, Chrome 11, Opera 11 and Webkit trunk ;
- limited to non-negative numbers: IE6 and IE9 (I assume 7 and 8 too) ;
- limited to non-negative numbers greater than zero: Firefox 4.

Given that the current specs state isn't web compatible and IE6/9 have select.size limited to non-negative numbers, we can probably have select.size limited to non-negative numbers instead of non-negative numbers greater than zero.

For information. the tree Gecko bugs:
https://bugzilla.mozilla.org/show_bug.cgi?id=639175 (issue with Yahoo Answers)
https://bugzilla.mozilla.org/show_bug.cgi?id=640636 (issue with jQuery)
https://bugzilla.mozilla.org/show_bug.cgi?id=640800 (no website involved)

It goes without saying that these three bugs were involving select.size=0.
Comment 1 Mounir Lamouri 2011-03-14 02:27:02 UTC 
Even if I don't really think this bug need more arguments, select.size is currently in a situation where, this raises an exception:
var select = document.createElement('select');
select.size = select.size;

Given that 0 is the default value.
I believe this is seriously wrong...
Comment 2 Ian 'Hixie' Hickson 2011-05-07 19:17:26 UTC 
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Accepted
Change Description: see diff given below
Rationale: Concurred with reporter's comments.
Comment 3 contributor 2011-05-07 19:17:54 UTC 
Checked in as WHATWG revision r6119.
Check-in comment: select.size has odd legacy behaviour required for compat
http://html5.org/tools/web-apps-tracker?from=6118&to=6119
Comment 4 Aryeh Gregor 2011-05-10 17:42:05 UTC 
This introduces a contradiction.  In the IDL, "size" is an unsigned long, but the prose says it's limited to only non-negative numbers.  The prose for "limited to only non-negative numbers" is defined only for long, not unsigned long: "If a reflecting IDL attribute has a signed integer type (long) that is limited to only non-negative numbers . . ."

You probably meant to change the IDL type for "size" from "unsigned long" to "long".
Comment 5 Aryeh Gregor 2011-06-07 21:33:11 UTC 
*** Bug 12899 has been marked as a duplicate of this bug. ***
Comment 6 Michael[tm] Smith 2011-08-04 05:34:31 UTC 
mass-move component to LC1
Comment 7 Ian 'Hixie' Hickson 2011-08-15 04:21:05 UTC 
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Accepted
Change Description: see diff given below
Rationale: Yeah, that wasn't right. But the fix in comment 4 isn't quite right either. :-)
Comment 8 contributor 2011-08-15 04:21:24 UTC 
Checked in as WHATWG revision r6455.
Check-in comment: Actually fix r6119 properly.
http://html5.org/tools/web-apps-tracker?from=6454&to=6455
Comment 9 Aryeh Gregor 2011-08-15 19:34:24 UTC 
Looks good to me.