Zhiheng Wang wrote on 8/12/2009 8:12 PM:
>The first cut of the draft is attached below. It's sketchy but should
> hold much of our ideas. We are
> still actively working on it. Any interest and feedback on the draft are
> highly welcome.
For navigationType, how would bookmarks, XHR, iframes a
Hello,
We recently started a draft to provide timing-related APIs in browsers.
The goal is to add the missingpieces in webapp latency measurements using
Javascript. As a starter, right now we've only include a
minimum set of interfaces we consider necessary, which mainly focuse on the
time and
Anne van Kesteren wrote:
On Wed, 12 Aug 2009 17:13:57 +0200, Arun Ranganathan wrote:
Latest draft is:
http://dev.w3.org/2006/webapi/FileUpload/publish/FileAPI.html
Thanks Arun!
Anne van Kesteren wrote:
I have not received any feedback on my comments as to why getAsDataURL
On Wed, Aug 12, 2009 at 4:33 PM, Ian Hickson wrote:
> On Mon, 3 Aug 2009, Aaron Boodman wrote:
>> >
>> > The API was intentionally made more obviously synchronous to avoid
>> > having to make people use callbacks.
>> >
>> > Would making all transactions automatically rollback if not committed
>> >
Garrett Smith wrote:
Good to get more notice on the API, but saying things like "Arun is a
great guy" in that same entry indicates impartiality.
He's a reasonably good guy, though :-)
AISB, the "2006" uri returns the latest "editors draft" and the
"Latest public version" at "/TR/file-upload
On Mon, 3 Aug 2009, Aaron Boodman wrote:
> >
> > The API was intentionally made more obviously synchronous to avoid
> > having to make people use callbacks.
> >
> > Would making all transactions automatically rollback if not committed
> > when the event loop spins be an acceptable substitute solu
There are quite a few things I'd like to do still on this draft, leaving
aside the question of changing the API, which I'd like to see more
discussion on [1]. It's worth documenting these things as "ToDos" so
the WG knows I'm working on them:
1. Terser, clearer prose on asynchronous accessor
On Wed, Aug 12, 2009 at 1:55 PM, Arun Ranganathan wrote:
> Dan Connolly wrote:
>>
>> Looks like the word is getting out about this work;
>> there's a pretty favorable article on ajaxian.
>> http://ajaxian.com/archives/w3c-publish-first-working-draft-of-file-api
>>
>> But it's a little confused...
>
On Wed, 2009-08-12 at 13:55 -0700, Arun Ranganathan wrote:
[...]
> Fixed; I hope the status is clearer now
yes; thanks for the quick fix.
> (you may have to force a reload
> to see the changes).
> http://dev.w3.org/2006/webapi/FileUpload/publish/FileAPI.html
>
> -- A*
--
Dan Connolly, W3C htt
Dan Connolly wrote:
Looks like the word is getting out about this work;
there's a pretty favorable article on ajaxian.
http://ajaxian.com/archives/w3c-publish-first-working-draft-of-file-api
But it's a little confused...
"The W3C has published a working draft for the File API"
W3C hasn't actual
Looks like the word is getting out about this work;
there's a pretty favorable article on ajaxian.
http://ajaxian.com/archives/w3c-publish-first-working-draft-of-file-api
But it's a little confused...
"The W3C has published a working draft for the File API"
W3C hasn't actually published it just y
On Wed, Aug 12, 2009 at 12:01 PM, Anne van Kesteren wrote:
> On Wed, 12 Aug 2009 20:09:20 +0200, Jonas Sicking wrote:
>> On Wednesday, August 12, 2009, Anne van Kesteren
>> wrote:
>>> On Tue, 11 Aug 2009 22:57:51 +0200, Jonas Sicking
>>> wrote:
xhr.open("GET", myFile.slice(x, y).fileDataURI
On Wed, 12 Aug 2009 20:09:20 +0200, Jonas Sicking wrote:
> On Wednesday, August 12, 2009, Anne van Kesteren
> wrote:
>> On Tue, 11 Aug 2009 22:57:51 +0200, Jonas Sicking
>> wrote:
>>> xhr.open("GET", myFile.slice(x, y).fileDataURI);
>>> xhr.send();
>>
>> FWIW I'm opposed to abusing XMLHttpRe
On Wed, Aug 12, 2009 at 7:42 AM, Arun Ranganathan wrote:
>> What's the use-case for getAsBase64?
>
> It's generally hard to encode files and to send them to servers. While Data
> URLs give developers a convenient way to work with Base64, URL length
> limitations across user agents make it pretty t
On Wednesday, August 12, 2009, Anne van Kesteren wrote:
> On Tue, 11 Aug 2009 22:57:51 +0200, Jonas Sicking wrote:
>> xhr.open("GET", myFile.slice(x, y).fileDataURI);
>> xhr.send();
>
> FWIW I'm opposed to abusing XMLHttpRequest in this way and I actually think
> that when using the filedata URL
Anne van Kesteren wrote:
> On Wed, 12 Aug 2009 17:17:09 +0200, Stewart Brodie
wrote:
> > Please could you add an appendix in the latter that summarises what's
> > new in the new version?
>
> Is there anything the Abstract does not cover you would like to see
> mentioned?
The Abstract is good f
On Wed, 12 Aug 2009 17:13:57 +0200, Arun Ranganathan wrote:
> Latest draft is:
> http://dev.w3.org/2006/webapi/FileUpload/publish/FileAPI.html
Thanks Arun!
> Anne van Kesteren wrote:
>> I have not received any feedback on my comments as to why getAsDataURL
>> is actually needed. I still thi
On Wed, 12 Aug 2009 17:17:09 +0200, Stewart Brodie
wrote:
> Please could you add an appendix in the latter that summarises what's
> new in the new version?
Is there anything the Abstract does not cover you would like to see mentioned?
> I believe it is true to say that a "conforming user age
Michael Nordman wrote:
>The draft says a new UUID should be 'coined' for each method invocation.
(Why is that?) Given the coinage of a new url on each access, accessing it
thru an attribute feels a little odd.
This should have been an editor's note, and not a part of the spec.
text. The "uni
Anne van Kesteren wrote:
> Given the number of changes it seems best to simply publish another
> Working Draft for now of both XMLHttpRequest and XMLHttpRequest Level 2
> and see where that brings us. It would help if we have more
> implementations trying to seriously implement it so we could dec
Latest draft is:
http://dev.w3.org/2006/webapi/FileUpload/publish/FileAPI.html
Anne van Kesteren wrote:
Thanks for the update to the draft! Below some feedback:
In the table of contents the link to the filedata URL scheme is broken.
Fixed.
The Web IDL syntax needs to be updated. E.g. Fil
splice should synchronously return a new FileData object. No need for
asynchronous callback since no IO occurs.
Done, though I used Anne's suggestion to make it an attribute.
Whoops, no I didn't mean Anne's suggestion for slice -- I meant it for
getAsURL.
Also the current draft is:
http
Adam de Boor wrote:
this is a minor point, but I'm finding the name of the "splice" method to be
odd. To me splice means to join, and "slice" would seem a more appropriate
name. The Array object has both splice and slice, and the former is used for
removing and inserting data and modifies the arr
Jonas Sicking wrote:
A few comments:
Need to specify that all getAsX functions call the callback
*asynchronously*. Also need to integrate this with the HTML5 event
loop.
Done.
getAsBinary should be called getAsBinaryString so that once we have a
BinaryArray or some such we can add a getAsBi
Gregg Tavares wrote:
How about this?
Why make a new API for getting the contents of a file (local or otherwise)
when we already have one which is XHR?
What if FileList was just array of File objects where each File object is
just a URL in the format
"filedata: uuid, filename"
Then you can use
I will be out of the office starting Fri 08/07/2009 and will not return
until Mon 08/17/2009.
I will respond to your message when I return.
Garrett Smith wrote:
In glancing at some of the methods in FileAPI, I noticed some coding
errors.
There definitely were errors; thank you for catching them.
First, an overview explanation:
http://dev.w3.org/2006/webapi/FileUpload/publish/FileAPI.xhtml#dfn-getAsDataURL
|... If the call is su
Jonas Sicking wrote:
Here is an alternative proposal for an API for reading files:
[Constructor, Implements=EventTarget]
interface FileRequest {
readAsBinaryString(in FileData filedata);
readAsText(in FileData filedata, [Optional] in DOMString);
readAsDataURL(in File file);
abort();
The last XMLHttpRequest Working Draft was a Last Call Working Draft. As it
turned out a number of changes had to be made again. Meanwhile HTML5 also got
further along and integration with the event loop as well as the storage mutex
was desired. These are now integrated.
The Forms WG asked for a
Below is the draft agenda for the 13 August Widgets Voice Conference (VC).
Inputs and discussion before the meeting on all of the agenda topics
via public-webapps is encouraged (as it can result in a shortened
meeting).
-Regards, Art Barstow
Logistics:
Time: 22:00 Tokyo; 16:00 Helsinki; 15:0
On Wed, 12 Aug 2009 05:41:57 +0200, David Levin wrote:
> It appears that both Safari and Firefox ignore returned cookies from a
> cross origin xhr when the credentials flag is set to false. This behavior
> seems very reasonable.
> Should the XMLHttpRequest level 2 spec indicate that this is t
On Thu, 30 Jul 2009 20:38:24 +0200, David Levin wrote:
> In http://www.w3.org/TR/XMLHttpRequest2/#credentials, it
> says: "The credentials flag takes the values true and false, true by
> default..."
> Both Firefox and Safari have defaulted the value to "False" but the spec
> says the default is "T
On Tue, 11 Aug 2009 22:57:51 +0200, Jonas Sicking wrote:
> xhr.open("GET", myFile.slice(x, y).fileDataURI);
> xhr.send();
FWIW I'm opposed to abusing XMLHttpRequest in this way and I actually think
that when using the filedata URL scheme some kind of exception needs to be
thrown. Similarly to w
ISSUE-95: P&C CR: Conformance checker behavior intermixed with UA behavior
[Widgets]
http://www.w3.org/2008/webapps/track/issues/95
Raised by: Marcos Caceres
On product: Widgets
On 11-Aug-2009, Marcos raised this Issue against the 23-July-2009 P&C CR:
http://lists.w3.org/Archives/Public/publ
ISSUE-94: P&C CR: Try to fallback to default start files when src path is
invalid or not existing [Widgets]
http://www.w3.org/2008/webapps/track/issues/94
Raised by: Marcos Caceres
On product: Widgets
On 31-July-2009, Marcos raised this Issue against the 23-July-2009 P&C CR:
http://lists.w3.
ISSUE-93: P&C CR: deprecated, grandfathered, and redundant tags should be
skipped [Widgets]
http://www.w3.org/2008/webapps/track/issues/93
Raised by: Marcos Caceres
On product: Widgets
On 31-July-2009, Marcos raised this Issue against the 23-July-2009 P&C CR:
http://lists.w3.org/Archives/Pub
36 matches
Mail list logo
