- From: Philip Taylor <pjt47@cam.ac.uk>
- Date: Mon, 29 Dec 2008 20:54:16 +0000
- To: HTML WG <public-html@w3.org>
In the section "Reflecting content attributes in DOM attributes": "If a reflecting DOM attribute is a floating point number type (float) and it doesn't fall into one of the earlier categories, then, [...] On setting, the given value must be converted to the shortest possible string representing the number as a valid floating point number in base ten and then that string must be used as the new content attribute value." That appears to require mappings like: 1000 -> "1e3" or "1E3" 100 -> "100" or "1e2" or "1E2" 12e+34 -> "12e34" if you ignore that 12e34 isn't exactly representable as a float; something more like "120000000000000007304085773727301632" if you want a decimal number that represents the float's real (uh, actual) value Math.pow(2,-64) -> "542101086242752217003726400434970855712890625e-64" so it's ambiguous, and also weird. It would seem more sensible to use something like ECMAScript's Number.toString(), which appears to give: 1000 -> "1000" 100 -> "100" 12e34 -> "1.2e+35" Math.pow(2,-64) -> "5.421010862427522e-20" (But "1.2e+35" isn't a valid floating point number in HTML5, so something would have to be changed.) It would be nice to explicitly note that the float value will never be non-finite (since an exception will have been thrown earlier if you passed in a non-finite value), so it's clear that it doesn't matter that the spec doesn't define how to convert non-finite values into strings. -- Philip Taylor pjt47@cam.ac.uk
Received on Monday, 29 December 2008 20:55:14 UTC