Hixie - would you please provide a short status and plan for these docs?
-Thanks, Art Barstow
Original Message
Subject: Seeking comments on LCWDs of Server-events, Web Storage, Web
Workers; deadline 30-June-2010
Date: Tue, 22 Dec 2009 18:37:20 +0100
From: Arthur Barstow
Dear Doug, all,
i am participating the W3C Media Annotations Working Group [1] and co-
edit the API for Resource 1.0 document [2]. Since we are going to LC
soon, we want to initiate implementing the API specified. The main
intention is, that we translate the WebIDL specification of the API
On Wed, 2 Jun 2010, Arthur Barstow wrote:
Hixie - would you please provide a short status and plan for these docs?
1. Server-Sent Events
http://www.w3.org/TR/2009/WD-eventsource-20091222/
2. Web Storage
http://www.w3.org/TR/2009/WD-webstorage-20091222/
3. Web Workers
Le mercredi 02 juin 2010 à 13:40 +0200, Florian Stegmaier a écrit :
My overall question is, if you have any experience with WebIDL parser,
or perhaps could point me to a project, which is most up-to-date to
the current version of the WebIDL specification? I have also tried to
validate
I have been reading the specification on file section.
I would like to ask why not propose that File interface allow a create
method to let user save data for his use?
Resume:
Interface File extends Blob
{
attribute unsigned long long currentPosition;
readonly attribute signed long long
Below is the draft agenda for the June 3 Widgets Voice Conference (VC).
Inputs and discussion before the VC on all of the agenda topics
via public-webapps is encouraged (as it can result in a shortened
meeting). Please address Open/Raised Issues and Open Actions before the
meeting:
On 5/28/10 2:15 PM, ext Marcos Caceres wrote:
On Fri, May 28, 2010 at 4:52 PM, Robin Berjonro...@berjon.com wrote:
Hi Jim,
your comments reach us right after the WG decided to take the specification to
CR, but thankfully I was a bit slow with the editing so that we could take them
into
On Mon, May 24, 2010 at 9:41 PM, Shawn Wilsher sdwi...@mozilla.com wrote:
On 4/20/2010 11:46 AM, bugzi...@jessica.w3.org wrote:
The spec is unspecified as to what we should do when a database is opened
with
a different description than it was previously opened. I'd assume we'd
want to
http://www.w3.org/Bugs/Public/show_bug.cgi?id=9698
Jeremy Orlow jor...@chromium.org changed:
What|Removed |Added
Status|NEW |RESOLVED
On Fri, May 21, 2010 at 12:39 AM, Jonas Sicking jo...@sicking.cc wrote:
So you'd have to pass in the javascript expression as a string. This
certainly works but is more than a little ugly. It also complicates
the implementation a good bit since it now has to include a javascript
engine.
http://www.w3.org/Bugs/Public/show_bug.cgi?id=9832
Summary: keyPath is underspecified
Product: WebAppsWG
Version: unspecified
Platform: PC
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
http://www.w3.org/TR/file-writer-api/
On Tue, Jun 1, 2010 at 8:18 AM, Cristiano Sumariva sumar...@gmail.comwrote:
I have been reading the specification on file section.
I would like to ask why not propose that File interface allow a create
method to let user save data for his use?
Resume:
Finally cycling back on this.
Based on feedback from Olli and Anne, I have revised the spec.
Changes:
* changed the setPriority() method to be an attribute priority
* made priority be a string rather than a number
* inserted the NORMAL priority as the default XHR priority
Here is the
It keeps seeming to me that moving the file-writer spec to WebApps
would make much more sense...
/ Jonas
2010/6/2 Ian Fette (イアンフェッティ) ife...@google.com:
http://www.w3.org/TR/file-writer-api/
On Tue, Jun 1, 2010 at 8:18 AM, Cristiano Sumariva sumar...@gmail.com
wrote:
I have been reading
I whole-heartedly agree, and have said as much in the past, both on public
MLs and to various W3C team contacts.
-Ian
On Wed, Jun 2, 2010 at 1:14 PM, Jonas Sicking jo...@sicking.cc wrote:
It keeps seeming to me that moving the file-writer spec to WebApps
would make much more sense...
/
I don't know who makes these decisions, but I'd imagine the editor
holds a certain amount of sway. I'd imagine that it would get a lot
more review and attention from browser companies on WebApps. Apple
isn't on DAP at all, and everyone from mozilla that works on related
APIs are not on the DAP
On Fri, 16 Apr 2010 07:00:56 +0100, Anne van Kesteren ann...@opera.com
wrote:
On Wed, 14 Apr 2010 01:13:46 +0900, Mike Belshe mbel...@google.com
wrote:
// Set the load priority for this request.
void setPriority(unsigned short priority);
Any reason this is not an attribute named
I'm reaching out to some W3C team contacts to figure out logistics.
-Ian
On Wed, Jun 2, 2010 at 2:02 PM, Jonas Sicking jo...@sicking.cc wrote:
I don't know who makes these decisions, but I'd imagine the editor
holds a certain amount of sway. I'd imagine that it would get a lot
more review
Also, for the sake of keeping things together, when we move this over we
should probably move FileSystem over as well.
-Ian
On Wed, Jun 2, 2010 at 3:27 PM, Ian Fette (イアンフェッティ) ife...@google.comwrote:
I'm reaching out to some W3C team contacts to figure out logistics.
-Ian
On Wed, Jun 2,
Makes sense to me. (Though I'm still not convinced of its usefulness).
/ Jonas
2010/6/2 Ian Fette (イアンフェッティ) ife...@google.com:
Also, for the sake of keeping things together, when we move this over we
should probably move FileSystem over as well.
-Ian
On Wed, Jun 2, 2010 at 3:27 PM, Ian
Arun:
In the latest version of the spec I see that readAsDataURL, alone
among the readAs* methods, still takes a File rather than a Blob. Is
that just an oversight, or is that an intentional restriction?
Eric
On Thu, May 13, 2010 at 5:27 AM, Arun Ranganathan a...@mozilla.com wrote:
On 6/2/10 3:42 PM, Eric Uhrhane wrote:
Arun:
In the latest version of the spec I see that readAsDataURL, alone
among the readAs* methods, still takes a File rather than a Blob. Is
that just an oversight, or is that an intentional restriction?
That's intentional; readAsDataURL was cited
On Wed, Jun 2, 2010 at 3:44 PM, Arun Ranganathan a...@mozilla.com wrote:
On 6/2/10 3:42 PM, Eric Uhrhane wrote:
Arun:
In the latest version of the spec I see that readAsDataURL, alone
among the readAs* methods, still takes a File rather than a Blob. Is
that just an oversight, or is that an
On 6/2/10 3:48 PM, Eric Uhrhane wrote:
Sure, why not? Why would this be limited to File objects?
A File is supposed to refer to an actual file on the local hard drive.
A Blob is a big bunch of data that you might want to do something
with. There's nothing special about a File when it comes
On Wed, Jun 2, 2010 at 3:48 PM, Eric Uhrhane er...@google.com wrote:
On Wed, Jun 2, 2010 at 3:44 PM, Arun Ranganathan a...@mozilla.com wrote:
On 6/2/10 3:42 PM, Eric Uhrhane wrote:
Arun:
In the latest version of the spec I see that readAsDataURL, alone
among the readAs* methods,
On Wed, Jun 2, 2010 at 3:57 PM, Arun Ranganathan a...@mozilla.com wrote:
On 6/2/10 3:48 PM, Eric Uhrhane wrote:
Sure, why not? Why would this be limited to File objects?
A File is supposed to refer to an actual file on the local hard drive.
A Blob is a big bunch of data that you might want
Hi, Arun,
I have one question regarding the scheme for Blob.url. The latest spec says
that The proposed URL scheme is filedata:. Mozilla already ships with
moz-filedata:. Since the URL is now part of the Blob and it could be used
to refer to both file data blob and binary data blob, should we
On Wed, Jun 2, 2010 at 3:42 PM, Eric Uhrhane er...@google.com wrote:
Arun:
In the latest version of the spec I see that readAsDataURL, alone
among the readAs* methods, still takes a File rather than a Blob. Is
that just an oversight, or is that an intentional restriction?
Having
On 6/2/10 5:06 PM, Jian Li wrote:
Hi, Arun,
I have one question regarding the scheme for Blob.url. The latest spec says
that The proposed URL scheme is filedata:. Mozilla already ships with
moz-filedata:. Since the URL is now part of the Blob and it could be used
to refer to both file data blob
I got what you mean. Thanks for clarifying it.
Do you plan to add the origin encoding into the spec? How about using more
generic scheme name blobdata:?
Jian
On Wed, Jun 2, 2010 at 5:26 PM, Arun Ranganathan a...@mozilla.com wrote:
On 6/2/10 5:06 PM, Jian Li wrote:
Hi, Arun,
I have one
On Wed, Jun 2, 2010 at 5:26 PM, Arun Ranganathan a...@mozilla.com wrote:
On 6/2/10 5:06 PM, Jian Li wrote:
Hi, Arun,
I have one question regarding the scheme for Blob.url. The latest spec
says
that The proposed URL scheme is filedata:. Mozilla already ships with
moz-filedata:. Since the
31 matches
Mail list logo