[Bug 17859] Mechanism to enable localisation of form controls and other locale-specific data

https://www.w3.org/Bugs/Public/show_bug.cgi?id=17859

--- Comment #36 from Ian 'Hixie' Hickson <ian@hixie.ch> ---
> I was considering the possibility that :locale() might be needed to allow
> CSS rules to target specific localizations. It would match against either
> the platform locale or page locale depending on which was enabled (pending
> such a feature in CSS).

Ah, I see. That's one option. I was thinking more that the page locale would be
set by the page (e.g. using lang=""), the platform locale would be set by the
user (in system settings), and the CSS side would just let you specify which of
those two locales to use when customising something, plus the ability to
specify dedicated formats. As in:

   span.currency { content: format(page-locale, contents, 'USD') }

...to take the element's contents, format it according to the page's locale,
and put that in the rendering (assuming USD as the currency).

Similarly:

   span.currency { content: format(user-locale, contents, attr(data-currency))
}
   span.currency { content: format('%03.2f %currency', attr(data-price),
attr(data-currency))) }

We also need a way to configure the input control bindings somehow to enable or
disable localisation. I don't know exactly how this should work. I'll let the
Web Components guy figure that out.


>   span.currency:locale(en-AU)::after {
>    content: "USD";
>   }

Being able to select based on the user's locale is an interesting idea, but
somewhat orthogonal to this issue, I think.


> Dates in the form "YYYY-MM-DD" is an international syntax and does not exist
> as a cultural format in any locale.

Yet my system platform's locale is set to use that as a date format. And I want
Web pages to honour that.


> This was the main thrust for <data> (and <time>).

Is was the main thrust for the original <time>, but that was dropped. <data> is
just for storing machine-readable data, the browser isn't supposed to do
anything with it. The new <time> is similar, but for time data. CSS hopefully
one day will be able to localise both, either according to the page locale or
the user locale.


> One further point is regarding the level of integration with BCP-47 locale
> extensions. Has any thought been given to the potential for manifesting each
> of the following attributes:
> 
> calendar
> time zone data 
> collation order
> currency
> number system
> 
> It seems that each of these has a place within HTML, if not the method to
> define their application.

Not sure what you mean.


> Consider potential use cases for:
> 
> <label>Enter Date/Time from the Japanese calendar</label>
> <input type="datetime" lang="en-u-ca-japanese"/>
> 
> <label>Enter Date/Time from the UTC-14 timezone</label>
> <input type="datetime" lang="en-u-tz-utce14"/>
> 
> <label>Select/Enter your phonebook names</label>
> <select lang="en-u-co-phonebk" editable multiple sorted/>
> 
> <label>Enter some $USD</label>
> <input type="currency" lang="en-u-cu-usd""/>
> 
> <label>Enter a Roman numeral</label>
> <input type="number" lang="en-u-nu-roman"/>

I don't really understand the use cases here. When would you want someone to
enter a roman numeral, only for it to be converted to a decimal value, instead
of just letting the author enter the value in whatever form they want that
their browser accepts, for example?

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Received on Friday, 1 August 2014 19:55:58 UTC