I'd like to see the resolution for this, too.
If what is held inside the browser for a Date object is just a double
or a long long value of the JS [[PrimitiveValue]] internal property
for Date, I guess providing programming language specific bindings for
Date would be easy (java.util.Date in
On Apr 23, 2010, at 20:08 , Shawn Wilsher wrote:
On 4/23/2010 7:39 AM, Nikunj Mehta wrote:
Could we create an additional optional parameter for an open request with
the type of permanence required? Or is it not a good idea?
I haven't talked to anyone at Mozilla that thinks that having
On Apr 26, 2010, at 11:38 , Marcos Caceres wrote:
2010/4/23 Nebojša Ćirić c...@chromium.org:
We would like to propose an API for locale-based collation,
date/number formatting, ... Does anybody else think this would benefit
the authors?
We would be happy to answer questions to what
Hi,
I think that Internationalization support in JavaScript has been too long
overlooked and represents a barrier to development of multilingual web sites.
The Internationalization WG actually approached the ECMASCript folks about
providing for international support in the JavaScript language.
We have a first draft at
http://docs.google.com/Doc?id=dhttrq5v_0c8k5vkdh (it has view/edit
permissions).
It's describes a small subset of final API we intend to implement.
We've picked date/time formatting and collation as must have for the
first iteration.
We feel there are, at least, two open
On Tue, Apr 20, 2010 at 4:22 PM, Jonas Sicking jo...@sicking.cc wrote:
On Tue, Apr 20, 2010 at 3:51 PM, Jian Li jia...@chromium.org wrote:
According to the spec, we will dispatch a progress event for a read
method.
But per the Progress Events 1.0 spec, the attributes loaded and
total
are
The current version of File API does not refer to the latest version of
ProgressEvent and thus I am seeing unsigned long, instead of unsigned
long long being used.
Certainly for unsigned long long, we could only treat it as EMCAScript
Number types not greater than 2^53.
On Mon, Apr 26, 2010 at
On 4/21/10 1:51 AM, Jian Li wrote:
According to the spec, we will dispatch a progress event for a read
method. But per the Progress Events 1.0 spec, the attributes loaded
and total are defined as unsigned long.
interface ProgressEvent : events::Event {
...
readonly
On 4/21/10 1:51 AM, Jian Li wrote:
According to the spec, we will dispatch a progress event for a read
method. But per the Progress Events 1.0 spec, the attributes loaded
and total are defined as unsigned long.
interface ProgressEvent : events::Event {
...
readonly
On Mon, Apr 26, 2010 at 3:21 PM, Darin Fisher da...@chromium.org wrote:
There is some interest from application developers at Google in being able
to get a Blob corresponding to the response body of a XMLHttpRequest.
The use case is to improve the efficiency of getting a Blob from a binary
On Mon, Apr 26, 2010 at 3:52 PM, Jonas Sicking jo...@sicking.cc wrote:
On Mon, Apr 26, 2010 at 3:39 PM, Darin Fisher da...@chromium.org wrote:
On Mon, Apr 26, 2010 at 3:29 PM, Jonas Sicking jo...@sicking.cc wrote:
On Mon, Apr 26, 2010 at 3:21 PM, Darin Fisher da...@chromium.org
wrote:
On Mon, Apr 26, 2010 at 3:57 PM, Ian Hickson i...@hixie.ch wrote:
On Mon, 26 Apr 2010, Jonas Sicking wrote:
Can we please rename .URN to .URL for consistency with the rest of the
platform? It really sticks out like a sore thumb being the only one
that's different... I'm worried people are
On Mon, Apr 26, 2010 at 4:02 PM, James Robinson jam...@google.com wrote:
On Mon, Apr 26, 2010 at 3:52 PM, Jonas Sicking jo...@sicking.cc wrote:
On Mon, Apr 26, 2010 at 3:39 PM, Darin Fisher da...@chromium.org wrote:
On Mon, Apr 26, 2010 at 3:29 PM, Jonas Sicking jo...@sicking.cc wrote:
On
On Mon, Apr 26, 2010 at 4:01 PM, Michael Nordman micha...@google.com wrote:
On Mon, Apr 26, 2010 at 3:52 PM, Jonas Sicking jo...@sicking.cc wrote:
On Mon, Apr 26, 2010 at 3:39 PM, Darin Fisher da...@chromium.org wrote:
On Mon, Apr 26, 2010 at 3:29 PM, Jonas Sicking jo...@sicking.cc wrote:
On Mon, 26 Apr 2010, Jonas Sicking wrote:
I initially implemented an uppercased name, but when I was writing test
cases for this property it was incredibly awkward to use the uppercased
version and I kept mistyping it using the lower cased name.
I would rather keep consistency with the
On Mon, Apr 26, 2010 at 4:19 PM, Thomas Broyer t.bro...@gmail.com wrote:
On Tue, Apr 27, 2010 at 1:11 AM, Jonas Sicking jo...@sicking.cc wrote:
I'm not sure I understand how you envision the implementation working.
You can't before hand know that the implementation won't ever access
those
On Mon, Apr 26, 2010 at 5:22 PM, Michael Nordman micha...@google.com wrote:
On Mon, Apr 26, 2010 at 4:24 PM, Jonas Sicking jo...@sicking.cc wrote:
On Mon, Apr 26, 2010 at 4:19 PM, Thomas Broyer t.bro...@gmail.com wrote:
On Tue, Apr 27, 2010 at 1:11 AM, Jonas Sicking jo...@sicking.cc wrote:
Discussions with several browser developers suggest exporting a flattened
data structure containing
all the DOMTiming objects on the page. Doing so allows site developers to
send the all the timing information
back for analysis without travelling the entire DOM tree. It helps minimize
the
18 matches
Mail list logo
