cira at chromium.org
Fri May 21 10:41:02 PDT 2010
thanks for quick reply. See my comments below.
On Thu, May 20, 2010 at 4:53 PM, Oliver Hunt <oliver at apple.com> wrote:
> It seems like the majority of this belongs in EcmaScript directly rather
> than being restricted to web-oriented uses of ES.
This is what Jungshik replied to the similar question on webapps list:
"I have two concerns about taking that direction:
First of all, I'm not sure of the wisdom of making a large set of i18n
APIs (locale, collation, formatting - number, date, message -, and more) a
standard library. If it had, wouldn't everybody agree that this should be a
have that notion. Does it mean we can/should add a slew of APIs to 'the
Secondly, I'm worried about the pace of the language
standardization process. I have an 'impression' (which may be totally off
the mark or
outdated) that the process is rather slow. On the other hand, WebApps WG
has been moving fast. We'd like to start with a working prototype of a
small subset of APIs fairly soon and iterate through WG to
In addition to the above concern, this is another reason we proposed
i18n APIs to WebApps WG instead of proposing that they be a part of the
i18n support is usually done through a library (e.g. ICU4C), only basic
things are built into the language itself, like support for UTF-16/32
I'm also unsure of the relevance of CommonJS to either WebAPI or ES as
> CommonJS is not part of either standards body. For example the use of
> "require" implies making CommonJS modules part of WebAPI, rather than any of
> the current modules proposals working through TC39.
My understanding is that CommonJS (formerly ServerJS) is gearing towards
becoming a standard library for ES. We mention it just to show how our API
can be implemented in CommonJS by simply replacing namespace from say
window.navigator.locale to some_module.locale.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the webkit-dev