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

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

Ian 'Hixie' Hickson <ian@hixie.ch> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
                 CC|                            |ian@hixie.ch
         Resolution|                            |WONTFIX

--- Comment #5 from Ian 'Hixie' Hickson <ian@hixie.ch> 2011-05-05 20:57:56 UTC ---
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.)

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.


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: 

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

-- 
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 Thursday, 5 May 2011 20:57:59 UTC