On Mon, 14 Nov 2011 17:55:25 +0100, Jonas Sicking jo...@sicking.cc wrote:
Yes, I think cross-origin should not work with sync. That is currently
the only synchronous communication mechanism cross origin. Without it a
UA
could put up UI if it wants to explicitly allow users to control such
Jonas Sicking wrote:
Hi everyone,
It was pointed out to me on twitter that BlobBuilder can be replaced
with simply making Blob constructable. I.e. the following code:
var bb = new BlobBuilder();
bb.append(blob1);
bb.append(blob2);
bb.append(some string);
bb.append(myArrayBuffer);
var b =
Right now, the spec does however handle that use case by doing this:
document.querySelectorAll(:scope .foo, x);
Where x is either an individual element, or an Array, NodeList or
numerically indexed object containing 0 or more Elements.
(It does however limit the result only to elements
On 2011-11-15 15:13, Brian Kardell wrote:
Right now, the spec does however handle that use case by doing this:
document.querySelectorAll(:scope .foo, x);
Where x is either an individual element, or an Array, NodeList or
numerically indexed object containing 0 or more Elements.
(It does
On Mon, Oct 24, 2011 at 6:52 PM, Jonas Sicking jo...@sicking.cc wrote:
It was pointed out to me on twitter that BlobBuilder can be replaced
with simply making Blob constructable. I.e. the following code:
I noticed this at https://developer.mozilla.org/en/Firefox_8_for_developers:
BlobBuilder
On Tue, Nov 15, 2011 at 10:55 AM, Glenn Maynard gl...@zewt.org wrote:
On Mon, Oct 24, 2011 at 6:52 PM, Jonas Sicking jo...@sicking.cc wrote:
It was pointed out to me on twitter that BlobBuilder can be replaced
with simply making Blob constructable. I.e. the following code:
I noticed this
On Tue, Nov 15, 2011 at 11:04 AM, Kyle Huey m...@kylehuey.com wrote:
I think we decided that we're going to remove getFile. See
https://bugzilla.mozilla.org/show_bug.cgi?id=669437#c7 and later.
FWIW, although I won't argue strongly for it here (we can always come back
to it), I don't think
On Tue, Nov 15, 2011 at 5:41 AM, Rich Tibbett ri...@opera.com wrote:
Jonas Sicking wrote:
Hi everyone,
It was pointed out to me on twitter that BlobBuilder can be replaced
with simply making Blob constructable. I.e. the following code:
var bb = new BlobBuilder();
bb.append(blob1);
A bit of back story: when designing and iterating the API, we focused
heavily on use cases. We were unable to come up with a compelling
(enough) use case for handling progress notifications, though the use
cases we did have allowed us to think of ways to modify the API to
support those use cases
I may be misunderstanding things, but I was thinking that saving a file
to the cloud.
FileSaver and XHR have onprogress events so users don't wonder too-much
about large file uploads.
Those are the only cases I was thinking of.
-Charles
On 11/15/2011 10:31 AM, James Hawkins wrote:
A bit
James wrote:
A bit of back story: when designing and iterating the API, we focused heavily
on use cases. We were unable to come up with a compelling
(enough) use case for handling progress notifications, though the use cases we
did have allowed us to think of ways to modify the API to
On Tue, Nov 15, 2011 at 4:22 AM, Anne van Kesteren ann...@opera.com wrote:
On Mon, 14 Nov 2011 17:55:25 +0100, Jonas Sicking jo...@sicking.cc wrote:
Yes, I think cross-origin should not work with sync. That is currently the
only synchronous communication mechanism cross origin. Without it a UA
On 11/15/2011 09:33 PM, Jonas Sicking wrote:
On Tue, Nov 15, 2011 at 4:22 AM, Anne van Kesterenann...@opera.com wrote:
On Mon, 14 Nov 2011 17:55:25 +0100, Jonas Sickingjo...@sicking.cc wrote:
Yes, I think cross-origin should not work with sync. That is currently the
only synchronous
On Tue, Nov 15, 2011 at 9:09 AM, Joshua Bell jsb...@chromium.org wrote:
I do however think that we should simply state that getting the index
values will use the normal method for looking up properties on JS
objects. This includes walking the prototype chain. Practically
speaking this only
On Tue, Nov 15, 2011 at 11:42 AM, Jonas Sicking jo...@sicking.cc wrote:
On Tue, Nov 15, 2011 at 9:09 AM, Joshua Bell jsb...@chromium.org wrote:
I do however think that we should simply state that getting the index
values will use the normal method for looking up properties on JS
objects.
http://usecases.webintents.org/
Though admittedly it's not complete, and we need to update the site
with a list of use cases we've rejected.
On Tue, Nov 15, 2011 at 11:30 AM, Josh Soref jso...@rim.com wrote:
James wrote:
A bit of back story: when designing and iterating the API, we focused
Since we don't have background intents (many reasons why, though we
looked into the idea), the service is responsible for displaying
progress UI for this use case.
For example imagine the service is Dropbox: the client initiates the
upload action and Dropbox is selected as the service by the
This is the way that I have implemented it in test apps. It is the handler
app that will show the progress information. I have not had a case yet
where the client app needs or is concerned about the progress of the action
that is being handled, other than on completion or on error.
I will
On Tue, Nov 15, 2011 at 11:41 AM, Olli Pettay olli.pet...@helsinki.fi wrote:
On 11/15/2011 09:33 PM, Jonas Sicking wrote:
On Tue, Nov 15, 2011 at 4:22 AM, Anne van Kesterenann...@opera.com
wrote:
On Mon, 14 Nov 2011 17:55:25 +0100, Jonas Sickingjo...@sicking.cc
wrote:
Yes, I think
On Tue, Nov 15, 2011 at 12:05 PM, Joshua Bell jsb...@chromium.org wrote:
On Tue, Nov 15, 2011 at 11:42 AM, Jonas Sicking jo...@sicking.cc wrote:
On Tue, Nov 15, 2011 at 9:09 AM, Joshua Bell jsb...@chromium.org wrote:
I do however think that we should simply state that getting the index
This is a comment from the W3C Technical Architecture Group on the last
call working draft: Web Storage [1].
The HTML5 Application Cache (AppCache) [2] and Local Storage [1] both
provide client-side storage that can be used by Web Applications. Although
the interfaces are different (AppCache
Sorry I messed up the subject of the first copy of this note. (I was
checking to make sure I got the title of the working draft right, put it in
the body of the note, and forgot the subject line). Please accept my
apologies...the risks of working in a hurry while running out the door.
Noah
On Tue, Nov 15, 2011 at 1:33 PM, Jonas Sicking jo...@sicking.cc wrote:
On Tue, Nov 15, 2011 at 12:05 PM, Joshua Bell jsb...@chromium.org wrote:
On Tue, Nov 15, 2011 at 11:42 AM, Jonas Sicking jo...@sicking.cc
wrote:
On Tue, Nov 15, 2011 at 9:09 AM, Joshua Bell jsb...@chromium.org
wrote:
On Tue, Nov 15, 2011 at 2:20 PM, Joshua Bell jsb...@chromium.org wrote:
On Tue, Nov 15, 2011 at 1:33 PM, Jonas Sicking jo...@sicking.cc wrote:
On Tue, Nov 15, 2011 at 12:05 PM, Joshua Bell jsb...@chromium.org wrote:
On Tue, Nov 15, 2011 at 11:42 AM, Jonas Sicking jo...@sicking.cc
wrote:
Could you quantify widely?
On Tue, Nov 15, 2011 at 3:47 PM, Adam Barth w...@adambarth.com wrote:
These APIs are quite widely used on the web. It seems unlikely that
we'll be able to delete either of them in favor of a single facility.
Adam
On Tue, Nov 15, 2011 at 2:05 PM, Noah Mendelsohn
But we should give it a try, no?
The spec are still Working Drafts.
All the best, Ashok
On 11/15/2011 2:47 PM, Adam Barth wrote:
These APIs are quite widely used on the web. It seems unlikely that
we'll be able to delete either of them in favor of a single facility.
Adam
On Tue, Nov 15,
Chromium devs put forward a unified quota API recently.
localStorage provides 5 megs of UTF16 storage; or about 2 megs of storage for
binary files saved as base64 strings. It's terrible for that use.
appCache had some Apis in existing proposals for programatically adding items.
I don't know if
From: ext Glenn Adams [gl...@skynav.com]
Could you quantify widely?
I think this definition of widely used is useful for this context:
http://caniuse.com/#search=storage
Personally, I see little to negative value in ignoring the fact the ship has
sailed for this spec.
-AB
On Tue, Nov 15,
On Tue, Nov 15, 2011 at 3:14 PM, Joshua Bell jsb...@chromium.org wrote:
On Tue, Nov 15, 2011 at 2:39 PM, Jonas Sicking jo...@sicking.cc wrote:
Hmm.. good point. Looking at the documentation for the built-in types,
there are unfortunately also a host of constant properties on implicit
Number
On Tuesday, November 15, 2011 4:33 PM, Jonas Sicking wrote:
On Tue, Nov 15, 2011 at 3:14 PM, Joshua Bell jsb...@chromium.org wrote:
On Tue, Nov 15, 2011 at 2:39 PM, Jonas Sicking jo...@sicking.cc wrote:
Hmm.. good point. Looking at the documentation for the built-in
types, there are
Extend, not delete.
On Nov 15, 2011, at 3:51 PM, ashok malhotra ashok.malho...@oracle.com wrote:
But we should give it a try, no?
The spec are still Working Drafts.
All the best, Ashok
On 11/15/2011 2:47 PM, Adam Barth wrote:
These APIs are quite widely used on the web. It seems
Perhaps. But widely implemented does not necessarily imply widely used. In
any case, support for or use of a feature of a WD or CR does not imply it
must be present in REC.
On Tue, Nov 15, 2011 at 5:21 PM, art.bars...@nokia.com wrote:
* From:* ext Glenn Adams [gl...@skynav.com]
* *
Could
On Tue, Nov 15, 2011 at 5:28 PM, Glenn Adams gl...@skynav.com wrote:
Perhaps. But widely implemented does not necessarily imply widely used. In
any case, support for or use of a feature of a WD or CR does not imply it
must be present in REC.
Use of a feature does, in fact, imply that, unless
* Tab Atkins Jr. wrote:
On Tue, Nov 15, 2011 at 5:28 PM, Glenn Adams gl...@skynav.com wrote:
Perhaps. But widely implemented does not necessarily imply widely used. In
any case, support for or use of a feature of a WD or CR does not imply it
must be present in REC.
Use of a feature does, in
Speaking for myself now, and not necessarily for the TAG:
I agree with those who say or imply that it's late for making incompatible
changes to the Web Storage specification. I'm less clear that's the case
for appcache, given comments about its many problems at the workshop last
week, but
35 matches
Mail list logo
