On 4.5.2012 23:17, Ian Hickson wrote:
On Fri, 27 Jan 2012, Bronislav Klu�~Mka wrote:
we are currently discussing localization in form fields, but that may
result in some unfortunate behavior if implemented alone, because data
will be displayed in localized representation in form fields but not in
HTML - server can translate text, but not localize data, since it has no
idea about local settings (language is not enough) and when data are
inserted into HTML on UA side using scripting, the problem is the same.
Suggestion
1/ output element
output element should follow similar logic for presentation as form fields
there is an example of output usage
http://dev.w3.org/html5/spec/the-output-element.html#the-output-element
<form onsubmit="return false" oninput="o.value = a.valueAsNumber +
b.valueAsNumber">
<input name=a type=number step=any> +
<input name=b type=number step=any> =
<output name=o></output>
</form>
but imagine full stop as thousands separator, comma as decimal , inserting
12.135,5 + 4.125,6 would result in 16261.1 (Number is fine, presentation
confusing)
so output element should follow presentation form of the forms as well
I agree. I think, though, that that's really something for the CSS layer
first. We can define all manner of data types and how they should be
localised, but without rendering-level support, it's not especially useful.
2/ FormatSettings object
[Constructor(),
Constructor(DOMString locale),
Constructor(FormatSettings locale),
]
interface FormatSettings {
attribute DOMString CurrencyString;
attribute Number CurrencyFormat;
attribute Number CurrencyDecimals;
attribute DOMString ThousandSeparator;
attribute DOMString DecimalSeparator;
attribute DOMString DateSeparator;
attribute DOMString TimeSeparator;
attribute DOMString ShortDateFormat;
attribute DOMString LongDateFormat;
attribute DOMString TimeAMString;
attribute DOMString TimePMString;
attribute DOMString ShortTimeFormat;
attribute DOMString LongTimeFormat;
attribute Array ShortMonthNames;
attribute Array LongMonthNames;
attribute Array ShortDayNames;
attribute Array LongDayNames;
attribute bool DaylightSavingTime;
attribute Number TimeZoneOffset;
DOMString format (String input, Array data)
Number CurrencyAsNumber (DOMString value)
Number StringAsNumber (DOMString value)
Date StringAsDate (DOMString value)
[and probably set of constants representing different types of error
regarding formatting and data sanitation]
}
What does the JS library space look like on this front? Is this something
that's done at all?
I agree that it makes sense to let Web pages style text to fit the user's
locale, but I don't think we should do it at the JS level if we can help
it. In particular, having the JS level have to explicitly use the
TimeSeparator for example seems like asking the authors to do too much
minutiae that could be taken care of at a higher level (CSS).
I can see you are pushing for CSS because of presentation level, but
1/ you need to display currency or number, what would you do?
<span style="format-type: number; format-decimal-separator:
',';">123.22</span>
something like that? I can see that, but would be better something like
<data role=number value=123.22 style="format-type: number;
format-decimal-separator: ',';" />
<data role=currency value=2.22 char=$ style="format-type: number;
format-decimal-separator: ','; format-currency-format: 2" />
this could enhance machine processing capabilities.
Nothing to do with JS API, you just brought me back to this already
discussed element.
We are discussing making data information universal (one data, several
localization).
2/ I would only assume that libraries for large, international projects
do contain such functionality, but there's no way to get the settings
from underlying OS.
3/ I would prefer moving with JS first, you can create display by
applying FormatSettings.format function (to get CSS functionality) but
it can give you additional functionality as well (FormatSettings
functions). Or essentially create both CSS and JS together as
complementary functionality.
Brona
