Re: [whatwg] Plus Signs in Signed Integers
On Tue, 14 Jul 2009, Jonas Sicking wrote: What does IE do in these two examples? It appears webkit treats the first one as start=4 and the second as start=0. In IE: ol start= 2liTEST/ol = 2 ol start=+2liTEST/ol = 2 ol start=-2liTEST/ol = -2 ol start=H2liTEST/ol = 1 ol start=.2liTEST/ol = 1 ol start=#2liTEST/ol = 1 This matches the spec. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Plus Signs in Signed Integers
What does IE do in these two examples? It appears that IE8 has the following behavior: ol start=+4 start = 4 ol start=H2SO4 start = 1 Test at http://stanford.edu/~jlebar/moz/list.html -Justin On Tue, Jul 14, 2009 at 12:43 AM, Jonas Sickingjo...@sicking.cc wrote: On Thu, Jun 18, 2009 at 9:33 AM, Smylerssmyl...@stripey.com wrote: It also doesn't seem to match browser behaviour: the ol element's start attribute is an integer, so I tried this out in various browsers: ol start=+4 liPlus four /ol All the ones I had to hand (Firefox, Opera, Konqueror, Dillo, Lynx, Links, and W3M) numbered the element with 4. [snip] To check that it is specifically the plus sign they are ignoring and not any non-digit character I also tried: ol start=H2SO4 liAcid test /ol That should cause parsing an integer to abort and so the default of start=1 to be used. Opera, Links, and W3M get that right. Konqueror, Dillo, and Lynx all also seem to manage the aborting, but use a default of zero instead. Firefox parses the 2 out of H2SO4, seemingly using the first integer it can find in the attribute, so possibly isn't special-casing +. What does IE do in these two examples? It appears webkit treats the first one as start=4 and the second as start=0. / Jonas
Re: [whatwg] Plus Signs in Signed Integers
On Mon, Jul 13, 2009 at 8:07 PM, Ian Hicksoni...@hixie.ch wrote: On Thu, 18 Jun 2009, Smylers wrote: The algorithm for parsing signed integers does not allow an optional plus sign before positive integers; that is, parsing +4 will return an error at step 8 of this algorithm: http://www.whatwg.org/html5#rules-for-parsing-integers That is inconsistent with the algorithm for non-negative integers, which tolerates (and ignores) a leading plus sign (step 6): http://www.whatwg.org/html5#rules-for-parsing-non-negative-integers I've made + be tolerated by the signed parser also. Based on what Boris said, why make this distinction? Generally +1 is not considered a valid integer by most number parsing libraries. And since gecko is planning on becoming more strict, why follow (part of) it's lead here? / Jonas
Re: [whatwg] Plus Signs in Signed Integers
On Tue, 14 Jul 2009, Jonas Sicking wrote: On Mon, Jul 13, 2009 at 8:07 PM, Ian Hicksoni...@hixie.ch wrote: On Thu, 18 Jun 2009, Smylers wrote: The algorithm for parsing signed integers does not allow an optional plus sign before positive integers; that is, parsing +4 will return an error at step 8 of this algorithm: http://www.whatwg.org/html5#rules-for-parsing-integers That is inconsistent with the algorithm for non-negative integers, which tolerates (and ignores) a leading plus sign (step 6): http://www.whatwg.org/html5#rules-for-parsing-non-negative-integers I've made + be tolerated by the signed parser also. Based on what Boris said, why make this distinction? Generally +1 is not considered a valid integer by most number parsing libraries. And since gecko is planning on becoming more strict, why follow (part of) it's lead here? I was basing the change on what IE does, not on what Gecko does. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Plus Signs in Signed Integers
On Thu, Jun 18, 2009 at 9:33 AM, Smylerssmyl...@stripey.com wrote: It also doesn't seem to match browser behaviour: the ol element's start attribute is an integer, so I tried this out in various browsers: ol start=+4 liPlus four /ol All the ones I had to hand (Firefox, Opera, Konqueror, Dillo, Lynx, Links, and W3M) numbered the element with 4. [snip] To check that it is specifically the plus sign they are ignoring and not any non-digit character I also tried: ol start=H2SO4 liAcid test /ol That should cause parsing an integer to abort and so the default of start=1 to be used. Opera, Links, and W3M get that right. Konqueror, Dillo, and Lynx all also seem to manage the aborting, but use a default of zero instead. Firefox parses the 2 out of H2SO4, seemingly using the first integer it can find in the attribute, so possibly isn't special-casing +. What does IE do in these two examples? It appears webkit treats the first one as start=4 and the second as start=0. / Jonas
Re: [whatwg] Plus Signs in Signed Integers
On Thu, 18 Jun 2009, Smylers wrote: The algorithm for parsing signed integers does not allow an optional plus sign before positive integers; that is, parsing +4 will return an error at step 8 of this algorithm: http://www.whatwg.org/html5#rules-for-parsing-integers That is inconsistent with the algorithm for non-negative integers, which tolerates (and ignores) a leading plus sign (step 6): http://www.whatwg.org/html5#rules-for-parsing-non-negative-integers I've made + be tolerated by the signed parser also. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Plus Signs in Signed Integers
Smylers wrote: ol start=H2SO4 liAcid test /ol That should cause parsing an integer to abort and so the default of start=1 to be used. Opera, Links, and W3M get that right. Konqueror, Dillo, and Lynx all also seem to manage the aborting, but use a default of zero instead. Firefox parses the 2 out of H2SO4 In Firefox, if the string doesn't look like an integer we end up calling some code that crazy-permissive string-to-integer parsing (which in particular skips over leading garbage). We plan to stop doing that, for what it's worth. seemingly using the first integer it can find in the attribute, so possibly isn't special-casing +. There is no special-casing of '+' in the non-crazy-permissive code, correct. That can be fixed, though. -Boris
