CSS styles exposed through the DOM should be treated as numbers (floats specifically) when the style takes a unitless float value. A simple example of this is opacity: el.style.opacity = 0.3; //works fine el.style.opacity = 1.3877787807814457e-16; // fails -- Webkit invalidates the style altogether (yielding opacity == 1.0) This will also fail for values specified in octal or hexadecimal, as they are treated as strings. This does work as expected in Firefox 1.5 (converting the numbers), however.
Created attachment 6681 [details] Test case: simple fader.
Created attachment 8069 [details] reduced test case
Trying to set the opacity to an invalid value such as 1e-16 has no effect in Firefox, but resets it in Safari. I'm not quite sure about what constitutes an invalid value, but the issue doesn't look like related to strings to me.
The so-called "invalid value" is a valid Number literal in JS. I suppose whether it's an "invalid value" depends entirely on whether the DOM as bound to by JS is supposed to only accept numbers in a specific format (decimal) or if any JS Number should be converted to a value suitable for DOM assignment.
(In reply to comment #4) > The so-called "invalid value" is a valid Number literal in JS. That's correct, but then it's converted back to a string and passed to CSS parser, which doesn't understand scientific notation. The problem with handling invalid values has been recently fixed, see bug 7296. The test case now works just like it does in Firefox. We just don't log an error to the console yet, unlike Firefox.