- From: David Singer <singer@apple.com>
- Date: Thu, 19 Jan 2012 15:19:12 -0800
On Jan 19, 2012, at 13:35 , Bronislav Klu?ka wrote: > > > On 19.1.2012 21:51, John Tamplin wrote: >> On Thu, Jan 19, 2012 at 3:38 PM, Ian Hickson<ian at hixie.ch> wrote: >> >>>>> On Thu, 14 Apr 2011, John Tamplin wrote: >>>>> Indeed. To solve this, we need help from CSS. That's one of the reasons we created<output> in HTML. >>>> This is about data representation and localization, not about optional >>>> stylistic suggestions, so CSS is a wrong way to deal with the issue. >>> I disagree. It's entirely a presentational issue. It's almost the >>> _definition_ of a presentational issue. >> >> I still disagree -- a user types "1,575" in a field. Is that interpreted >> as a value between 1 and 2 or between 1000 and 2000? Interpretation of the >> value entered by the user has nothing to do with CSS. >> > > This should depend on selected locale, is coma thousands or decimal separator? Browser should follow such settings and display value accordingly, but value MUST be sent to server according to 1 set of rules, regardless of anything else (e.g. no thousands separator and full stop as decimal separator). No browser locale, no server locale... one set of rules. > Consider JavaScript here... regardless of displayed value, you always get Number type out of it (not string like 15.123,55 but 15123.55) > So it is just display here, but spec should explain the difference between display value and underlying data. Yes. What the user enters and sees on screen is a presentational/locale issue mediated by the browser etc. What an API returns, a form sends, etc., when it is a number in string format, should be fixed. David Singer Multimedia and Software Standards, Apple Inc.
Received on Thursday, 19 January 2012 15:19:12 UTC