On Tue, Apr 27, 2010 at 2:04 PM, Jonas Sicking jo...@sicking.cc wrote:
On Tue, Apr 27, 2010 at 1:59 PM, Darin Fisher da...@chromium.org wrote:
On Tue, Apr 27, 2010 at 1:33 PM, Jonas Sicking jo...@sicking.cc wrote:
On Tue, Apr 27, 2010 at 1:26 PM, Darin Fisher da...@chromium.org
wrote:
Ugh, sent this originally to just Darin. Resending to the list.
On Wed, Apr 28, 2010 at 10:11 AM, Darin Fisher da...@chromium.org wrote:
On Tue, Apr 27, 2010 at 2:04 PM, Jonas Sicking jo...@sicking.cc wrote:
On Tue, Apr 27, 2010 at 1:59 PM, Darin Fisher da...@chromium.org wrote:
On Tue, Apr
On Tue, Apr 27, 2010 at 6:38 AM, Robin Berjon ro...@berjon.com wrote:
Hi,
On Apr 26, 2010, at 20:49 , Nebojša Ćirić wrote:
We have a first draft at
http://docs.google.com/Doc?id=dhttrq5v_0c8k5vkdh (it has view/edit
permissions).
That's interesting; personally I agree that this would be
On Wed, Apr 28, 2010 at 11:21 AM, Jonas Sicking jo...@sicking.cc wrote:
Ugh, sent this originally to just Darin. Resending to the list.
On Wed, Apr 28, 2010 at 10:11 AM, Darin Fisher da...@chromium.org wrote:
On Tue, Apr 27, 2010 at 2:04 PM, Jonas Sicking jo...@sicking.cc wrote:
On Tue,
Referring to the process:
Trying to get effective and useful internationalization supported in
ECMAScript has been a fruitless process (see Markus's memo of some seven or
eight years ago). It might be possible to get needed changes if one were to
spend enough (a huge amount of) time with the ECMA
I agree (and am empowered by the I18N WG to say so). I don’t think we need to
saddle the I18N efforts with the TC39 process but rather that what we do be
compatible and consistent with internationalization changes in ES6.0 that TC39
eventually really *MUST* take up---that we push forward with
On Wed, Apr 28, 2010 at 11:57 AM, Michael Nordman micha...@google.comwrote:
On Wed, Apr 28, 2010 at 11:21 AM, Jonas Sicking jo...@sicking.cc wrote:
Ugh, sent this originally to just Darin. Resending to the list.
On Wed, Apr 28, 2010 at 10:11 AM, Darin Fisher da...@chromium.org
wrote:
On
On Wed, Apr 28, 2010 at 12:45 PM, Darin Fisher da...@chromium.org wrote:
On Wed, Apr 28, 2010 at 11:57 AM, Michael Nordman micha...@google.com
wrote:
On Wed, Apr 28, 2010 at 11:21 AM, Jonas Sicking jo...@sicking.cc wrote:
Ugh, sent this originally to just Darin. Resending to the list.
On
On Wed, Apr 28, 2010 at 12:45 PM, Darin Fisher da...@chromium.org wrote:
On Wed, Apr 28, 2010 at 11:57 AM, Michael Nordman micha...@google.com
wrote:
On Wed, Apr 28, 2010 at 11:21 AM, Jonas Sicking jo...@sicking.cc wrote:
Ugh, sent this originally to just Darin. Resending to the list.
On
On Wed, Apr 28, 2010 at 7:48 PM, Gregg Tavares g...@google.com wrote:
I'm sorry if I'm not familiar with all the details of how the widgets spec
is going but the specs encourage comment so I'm commenting :-)
It seems like widgets have 2 uses
#1) As a way to package an HTML5 app that can be
shawn, did you have a chance to give this some thought? how would mozilla
like to handle cases like the ones jeremy and robin mentioned? how would you
like to manage quotas?
thanks,
dumi
On Fri, Apr 23, 2010 at 11:08 AM, Shawn Wilsher sdwi...@mozilla.com wrote:
On 4/23/2010 7:39 AM, Nikunj
On Wed, Apr 28, 2010 at 2:28 PM, timeless timel...@gmail.com wrote:
On Wed, Apr 28, 2010 at 7:48 PM, Gregg Tavares g...@google.com wrote:
I'm sorry if I'm not familiar with all the details of how the widgets
spec
is going but the specs encourage comment so I'm commenting :-)
It seems
On Wed, Apr 28, 2010 at 2:28 PM, timeless timel...@gmail.com wrote:
On Wed, Apr 28, 2010 at 7:48 PM, Gregg Tavares g...@google.com wrote:
I'm sorry if I'm not familiar with all the details of how the widgets
spec
is going but the specs encourage comment so I'm commenting :-)
It seems
On 4/28/2010 2:54 PM, Dumitru Daniliuc wrote:
shawn, did you have a chance to give this some thought? how would mozilla
like to handle cases like the ones jeremy and robin mentioned? how would you
like to manage quotas?
We chatted yesterday, but I haven't had a chance to get it down into
We had some discussions about this at mozilla yesterday. I think the
summary is something like this:
* We'd like to expire data in IndexDB after some time. This will
likely be based on heuristics, such as haven't visited the site for an
extended period of time, though possibly keep the data a bit
This thinking resonates with what we've been thinking too (I think).
On Wed, Apr 28, 2010 at 3:42 PM, Jonas Sicking jo...@sicking.cc wrote:
We had some discussions about this at mozilla yesterday. I think the
summary is something like this:
* We'd like to expire data in IndexDB after some
cool.
thankfully the way the standards stuff works, it's too late to change
any of this.
e.g. the standards group has already selected a signing mechanism to
which mozilla objects, but it can't be changed. similarly, zip can't
be replaced in widgets.
people are free to write replacement
On Wed, Apr 28, 2010 at 4:03 PM, Michael Nordman micha...@google.com wrote:
This thinking resonates with what we've been thinking too (I think).
On Wed, Apr 28, 2010 at 3:42 PM, Jonas Sicking jo...@sicking.cc wrote:
We had some discussions about this at mozilla yesterday. I think the
summary
On Wed, Apr 28, 2010 at 4:17 PM, Eric Uhrhane er...@google.com wrote:
On Wed, Apr 28, 2010 at 3:42 PM, Jonas Sicking jo...@sicking.cc wrote:
We had some discussions about this at mozilla yesterday. I think the
summary is something like this:
* We'd like to expire data in IndexDB after some
We probably want to have different policies for different kinds of devices.
For mobile, pruning unused storage is definitely important, but for modern
desktops with 1TB drives most users probably won't ever need to free up
disk space unless they're hit with some kind of denial-of-service attack,
On Wed, Apr 28, 2010 at 4:32 PM, Jonas Sicking jo...@sicking.cc wrote:
On Wed, Apr 28, 2010 at 4:03 PM, Michael Nordman micha...@google.com wrote:
We have in mind that the incentives for developers to not always utilize the
most permanent storage option are...
1) Non-permanent storage is
I've been going through this thread trying to figure out how to make
FileWriter [1] work cleanly for the various use cases presented, and I
think the reason I've been having so much trouble is that it's just a
bad idea to do so. Its original design constraints rule out some of
the use cases. I
On Wed, Apr 28, 2010 at 8:18 PM, Ian Hickson i...@hixie.ch wrote:
On Tue, 27 Apr 2010, Simon Pieters wrote:
Fine, fine. I've updated HTML5 to rename WebSocket.URL,
EventSource.URL, and Stream.URL to be lowercase.
Can you change it back? We've implemented and written tests for
On Thu, 29 Apr 2010 05:27:44 +0200, Jonas Sicking jo...@sicking.cc wrote:
Can you change it back? We've implemented and written tests for
WebSocket.URL. WebKit has implemented EventSource.URL and
WebSocket.URL.
Do you plan to implement the File API attribute as .URL also?
24 matches
Mail list logo
