[Bug 12296] Rules for parsing an integer don't match ES parseInt()

http://www.w3.org/Bugs/Public/show_bug.cgi?id=12296

Aryeh Gregor <Simetrical+w3cbug@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|WONTFIX                     |

--- Comment #6 from Aryeh Gregor <Simetrical+w3cbug@gmail.com> 2011-05-06 17:29:47 UTC ---
(In reply to comment #5)
> This is intended to match legacy attribute parsing. It's apparently not
> perfect, and I'm happy to address specific compatibility problems, but
> referring to ES' parseInt() here is a non-starter. For example, consider:
> 
>    <ol><li value="0x20">1
> 
> Firefox, Opera, and WebKit all get different results, but none of them match
> ES. (WebKit and IE agree on this case, but that's because they clamp to 1
> rather than 0 like the other browsers. Note that the spec here has removed
> clamping to allow negative numbers, but that's another issue.)

parseInt("0x20", 10) results in 0, which is the same as the current algorithm
in the spec.  Of course, parseInt("0x20") is 32, but I never said we should use
parseInt() without a radix argument.

> Or consider:
> 
>    <p
> tabindex="0x20"><script>w(document.getElementsByTagName('p')[0].tabIndex)</script>
> 
> Again, Firefox, Opera, and WebKit all get different results. The spec matches
> WebKit/IE for this one. ES doesn't match any of them.

See above.  parseInt("0x20", 10) is 0, same as the spec.

What's a case where the current algorithm gives different results from
parseInt(x, 10), *and* where the current algorithm's result is preferable?

> Regarding U+00A0 (NBSP), it's one of a number of areas where browsers happen to
> coincide and not match the spec, but overall the interoperability is pretty
> poor. Unless there are specific compatibility problems, I would much rather we
> keep the spec at the current pretty simple level rather than adding additional
> complexity to handle specific non-conforming cases that happen to be
> interoperable today.
> 
> Here's a test case that shows some of the weird behaviour in how characters are
> handled before the number:
>    http://www.hixie.ch/tests/adhoc/html/attribute-parsing/001.html

It would be much simpler if the spec just matched ES here, not more complex. 
You could simply defer to ES.  That's easier to spec, easier to implement, and
easier for authors to understand.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Friday, 6 May 2011 17:29:49 UTC