On Oct 16, 2011, at 11:02 AM, Mounir Lamouri wrote:

> On 10/16/2011 02:17 PM, Daniel Bates wrote:
>> How should overflow be handled when parsing integers?
>> 
>> Step 8 of the parsing algorithm in 
>> both<http://dev.w3.org/html5/spec/Overview.html#rules-for-parsing-integers>  
>> and<http://dev.w3.org/html5/spec/Overview.html#non-negative-integers>  
>> doesn't mention how to handle integer overflow when interpreting the result 
>> of a sequence of base-ten integers.
>> 
>> Currently in WebKit we consider such overflow a parsing error. Is there any 
>> reason not to consider overflow a parsing error? Regardless, I suggest 
>> codifying the handling of overflow in the aforementioned sections.
> 
> Gecko also considers that an overflow is a parsing error. Presto and IE6 
> doesn't seem to.
> The specs should probably mention this by whether consider it as a parsing 
> error or request the UA to default to the highest value (which Presto and IE6 
> seem to do but not using the same value).

Notice that spec tends to provide guidance when the rules for parsing a number 
return an error. For instance, the spec defines what happens when parsing the 
value of the tabindex attribute returns an error: 
<http://www.whatwg.org/specs/web-apps/current-work/multipage/editing.html#sequential-focus-navigation-and-the-tabindex-attribute>.

I suggest that we return an error in step 8 of the rules for parsing 
signed/non-negative integers when the sequence of characters cannot be 
interpreted as an base-ten integer that is representable using an integer 
datatype. Then we can leave it up to the relevant sections of the spec to 
define how to handle such a parser error (like in the case for tabindex), 
including whether to fall back to an agreed default value or leave it up to the 
UA (which may default to the highest value).

> 
>> This issue came up recently in WebKit with respect to the parsing of the 
>> maxlength attribute (https://bugs.webkit.org/show_bug.cgi?id=68981).
> 
> Actually, this problem wouldn't have been that annoying if Webkit was 
> following the specs regarding maxlength attribute: if the content attribute 
> value isn't a valid non-negative integer, the element has no maximum allowed 
> value length.

Thank you for bringing this up and directly commenting about this on the bug 
(https://bugs.webkit.org/show_bug.cgi?id=68981). Currently WebKit doesn't 
conform to this behavior. As mentioned by Kent Tamura on the bug, this issue is 
covered by WebKit bug #44883 (https://bugs.webkit.org/show_bug.cgi?id=44883).

Dan

Reply via email to