This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
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
To be clear, I'm talking about unsigned longs that are limited to only non-negative numbers greater than zero.
"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.
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.
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.
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.
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