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 10354 - What happens if you do an IDL get on size for <select size=0>? Does it return 0 or 1?
Summary: What happens if you do an IDL get on size for <select size=0>? Does it retur...
Alias: None
Product: HTML WG
Classification: Unclassified
Component: pre-LC1 HTML5 spec (editor: Ian Hickson) (show other bugs)
Version: unspecified
Hardware: Other other
: P3 normal
Target Milestone: ---
Assignee: Ian 'Hixie' Hickson
QA Contact: HTML WG Bugzilla archive list
Depends on:
Reported: 2010-08-12 20:32 UTC by contributor
Modified: 2010-10-04 13:57 UTC (History)
6 users (show)

See Also:


Description contributor 2010-08-12 20:32:47 UTC

"Zero is not allowed" is unclear as normative text.  What happens if you do an
IDL get on size for <select size=0>?  Does it return 0 or 1?  Browsers
disagree: Gecko and WebKit return 1, IE and Opera return 0.  At least in the
case of <select size=0>, returning 1 makes more sense, since that's how it's
displayed in all browsers.  Maybe you could also update the section on select
to say that the display size is 1 if it would otherwise be 0, or make a new
algorithm "rules for parsing positive integers" and use that.  Test case:
<!doctype html><script>var el = document.createElement("select");
el.setAttribute("size", "0"); alert(el.size);</script> 

Posted from:
Comment 1 Aryeh Gregor 2010-08-12 20:53:41 UTC
To be clear, I'm talking about unsigned longs that are limited to only non-negative numbers greater than zero.
Comment 2 Ms2ger 2010-08-14 16:41:30 UTC
"Zero is not allowed" isn't normative text. The IDL attribute should return 0. (See <>, which doesn't fail on 0, so

> ... must first be parsed according to the rules for parsing non-negative
> integers [and] the resulting value must be returned.

applies.) It probably makes sense to change

> and if that is successful, and the value is in the range of the IDL
> attribute's type,


> and if that is successful, the value is not zero and in the range of the IDL
> attribute's type,

or something like that.
Comment 3 Aryeh Gregor 2010-08-15 17:19:19 UTC
Yeah, I think the current spec is reasonably clear that it returns 0, but maybe it should be changed to return 1, at least for select.size.
Comment 4 Aryeh Gregor 2010-08-31 20:47:57 UTC
Just to be clear, since the preceding discussion was somewhat confused, the problem is 1) browsers disagree on whether to return 1 or 0 by default for select.size, 2) the spec mandates 0, but 3) 1 makes more sense in this case, so I don't want to file bugs against browsers without at least suggesting that the spec be changed.  I don't really care how this is worded in the spec, if it's changed.
Comment 5 Ian 'Hixie' Hickson 2010-09-25 18:55:38 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:

Status: Accepted
Change Description: see diff given below
Rationale: The interoperability here is nil, especially when you also look at how browsers handle size="" missing altogether, or size="a" (i.e. being set to an invalid value), and even more so when you start looking at other attributes with similar rules. So I've moved away from IE compat here (which is what I had been trying to go for earlier with these rules) and have specified this somewhat more sanely, such that it never returns 0.
Comment 6 contributor 2010-09-25 18:56:23 UTC
Checked in as WHATWG revision r5495.
Check-in comment: select.size should never return 0 (also affects other attributes)