Values that are out of range (can't be expressed by the IDL attribute) return 0.0. (See bug 8046.)

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: Accepted
Change Description: see diff given below
Rationale: Concurred with reporter's comments.

If the new text isn't clear enough, please suggest better text.

Checked in as WHATWG revision r4331.
Check-in comment: Try to be more explicit about what happens with parsing strings into floats for out-of-range or over-precise values.
http://html5.org/tools/web-apps-tracker?from=4330&to=4331

It seems clearer now, but weird, because it doesn't match how floats are parsed in ECMAScript (or any other environments I'm aware of, though that's not many).

E.g. the string
  "1.00000000000000012"
in common ECMAScript implementations gets converted to the number
   1.0000000000000002
(and if you subtract 1 then you get 2.220446049250313e-16)
whereas HTML5 now just talks about "truncating", so it would end up with the number 1.0 (being the next lowest representable number).

I don't see any reason to differ from ES, and doing so seems like it could make implementations more complex (since they couldn't be based on existing float-parsing code).

ES defines ToNumber as truncating after the 20th significant digit and then (optionally) incrementing the 20th significant digit, and then doing round-to-nearest with ties-to-even. But these are (32-bit) floats, not Numbers, so HTML5 can't do exactly the same.

It might be better to copy the definition from http://dev.w3.org/2006/webapi/WebIDL/#es-float , saying something like:

    "A number n is <dfn>converted to an IDL float value</dfn> by running the following algorithm:
    1. Let S be the set of finite IEEE 754 single-precision floating point values except &#8722;0, but with two special values added: 2^128 and &#8722;2^128.
    2. Let V be the number in S that is closest to n, selecting the number with an even significand if there are two equally close values. (The two special values 2^128 and &#8722;2^128 are considered to have even significands for this purpose.)
    3. If V is 2^128, return +&#8734;.
    4. If V is &#8722;2^128, return &#8722;&#8734;.
    5. Return V.

    ...

    If a reflecting IDL attribute is a floating point number type (float), then, on getting, the content attribute must be parsed according to the rules for parsing floating point number values, and if that is successful, the number must be <a href>converted to an IDL float value</a>; and if the resulting value is finite, then that value must be returned. If, on the other hand, the parsing fails or the conversion returns an infinite value, ..."

(n can't be NaN or &#8722;0, so those cases aren't handled here.)

I doubt that is perfectly correct (perhaps n needs to be truncated before rounding?), and it would be good if someone who understands floating point parsing properly could suggest something better, but I think this is better than what the spec says now.

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: Accepted
Change Description: see diff given below
Rationale: Concurred with reporter's comments.

Checked in as WHATWG revision r4348.
Check-in comment: Redefine how to parse floats so that they are always narrowed to 32bit floats.
http://html5.org/tools/web-apps-tracker?from=4347&to=4348

My original doubt was about numbers like 1 + 2^-53:

1.00000000000000011102230246251565404236316680908203125

where a perturbation in the final digit can change whether the closest (double-precision) number is 1.0 or 1.0+epsilon. ECMAScript explicitly truncates strings to 20 significant digits before rounding, so implementations don't have to (but may) examine an unlimited number of characters.

However, it looks like most browser JS implementations do examine every digit when parsing numbers. (Only IE and Opera-on-Linux appear to truncate.)

So it seems the truncation behaviour is not necessary, and what HTML5 currently defines is reasonable and implementable, as far as I can tell. Implementors can complain if they don't like it. (And in practice it only matters in crazy edge cases anyway.)