W3C home > Mailing lists > Public > public-html@w3.org > December 2008

Stringifying reflected float attributes

From: Philip Taylor <pjt47@cam.ac.uk>
Date: Mon, 29 Dec 2008 20:54:16 +0000
Message-ID: <495938F8.20803@cam.ac.uk>
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
Received on Monday, 29 December 2008 20:55:14 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 9 October 2021 18:44:40 UTC