10354 2010-08-12 20:32:47 +0000 What happens if you do an IDL get on size for <select size=0>? Does it return 0 or 1? 2010-10-04 13:57:18 +0000 1 1 1 Unclassified HTML WG pre-LC1 HTML5 spec (editor: Ian Hickson) unspecified Other other CLOSED FIXED http://www.whatwg.org/specs/web-apps/current-work/#reflecting-content-attributes-in-idl-attributes P3 normal --- 1 contributor ian ayg ian mike Ms2ger public-html-admin public-html-wg-issue-tracking public-html-bugzilla oldest_to_newest 37375 0 contributor 2010-08-12 20:32:47 +0000 Section: http://www.whatwg.org/specs/web-apps/current-work/#reflecting-content-attributes-in-idl-attributes Comment: "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: 68.175.61.233 37376 1 ayg 2010-08-12 20:53:41 +0000 To be clear, I'm talking about unsigned longs that are limited to only non-negative numbers greater than zero. 37417 2 Ms2ger 2010-08-14 16:41:30 +0000 "Zero is not allowed" isn't normative text. The IDL attribute should return 0. (See <http://www.whatwg.org/specs/web-apps/current-work/multipage/common-microsyntaxes.html#rules-for-parsing-non-negative-integers>, 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, to > and if that is successful, the value is not zero and in the range of the IDL > attribute's type, or something like that. 37430 3 ayg 2010-08-15 17:19:19 +0000 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. 38351 4 ayg 2010-08-31 20:47:57 +0000 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. 39387 5 ian 2010-09-25 18:55:38 +0000 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: 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. 39388 6 contributor 2010-09-25 18:56:23 +0000 Checked in as WHATWG revision r5495. Check-in comment: select.size should never return 0 (also affects other attributes) http://html5.org/tools/web-apps-tracker?from=5494&to=5495