[Webkit-unassigned] [Bug 18994] LANG/LC_ALL influences the result of element.style.opacity
bugzilla-daemon at webkit.org
bugzilla-daemon at webkit.org
Mon May 12 12:09:19 PDT 2008
http://bugs.webkit.org/show_bug.cgi?id=18994
------- Comment #6 from digulla at hepe.com 2008-05-12 12:09 PDT -------
I couldn't find anything :/ I doubt that glibc offers this after finally
offering automatic locale specific formatting.
Why does the parseDouble() function expect "." even when the locale specifies
","?
Also, I wonder what a fix in String::format() would break. Will it work for
JavaScript, too? Like:
var x = 1.5;
var s = "" + x;
assert "1.5" == s;
My next idea was to set LANG/LC_ALL in the startup script but that would break
if someone would embed WebKit in an application.
Or we could patch the field "decimal_point" in "struct lconv". But that might
introduce even more hideous bugs during embedding, especially when threads are
used.
Which leads to another question: Might the web developer want to *show* float
values to the user? In this case, which locale should be used to format them?
C? The locale of the page? The locale in which the browser runs?
Argh... a Pandora Bug!
If everyone was using String::number(double) to format double values, we could
replace "," by "." in there. But that isn't very safe as long as
String::format() is not private (someone might try to format double values
manually, for example in a more complex format string).
The GNU header file locale.h mentions that there is some proof of concept code
to allow per-thread locales. But I'm not sure how fast this is (i.e. getting
the current locale, replace it with C, set it back after the double value has
been formatted).
*sigh* It would be easier if style.opacity would simply return a double value
:)
I'll keep my eyes open for a solution for this but half an hour on Google
didn't turn anything really useful up. Maybe ask the glibc maintainers for
help?
--
Configure bugmail: http://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
More information about the webkit-unassigned
mailing list