This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
This issue was brought up in the WHATWG email thread <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2011-October/033508.html>. The sections on parsing signed/non-negative integers doesn't describe what should happen when the sequence of collected characters interpreted as a base ten-integer isn't representable using an integer datatype. In particular, step 8 in both of these sections doesn't mention how to handle this case. Because the rules for parsing a signed/non-negative integer don't return an error for such a case, it's up to the UA to handle it as it sees best despite the fact that many portions of the spec have defined behavior for handling an error that is returned when parsing an integer (e.g. "Sequential focus navigation and the tabindex attribute"). That is, the spec isn't always falling back on its error handling definitions when it could.
It seems that reflection takes into account overflow [1] but it should probably be moved somewhere else or the check of "in attribute type range" should be copy-pasted at a lot of places. For example, if maxlength content attribute is a too high number, higher than long range, maxlength IDL attribute will return -1. However, the input element will be considered as having a maxlength and the maxlength value should be used to check if the element's value is too long [2]. I'm not sure what would be the best way to handle that.. [1] http://www.whatwg.org/specs/web-apps/current-work/multipage/common-dom-interfaces.html#reflecting-content-attributes-in-idl-attributes [2] www.whatwg.org/specs/web-apps/current-work/multipage/association-ofcontrols-and-forms.html#maximum-allowed-value-length
The browser is supposed to have infinite range internally; handling overflow due to hardware limitations (e.g. because it's impractical to have a 1024 bit integer field) is left up to the UA in the hardware limitations clause. The JS interface takes out-of-JS-range values and converts them, as noted in comment 1. This is all as intended.
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: Rejected Change Description: no spec change Rationale: see comment 2. If there's a reason to change this, though, please don't hesitate to reopen the bug and explain the rationale (e.g. that it causes particular real-world practical compatibility problems, that it has some security implications, or some other rationale).