On May 23, 2012, at 9:58 AM, Glenn Maynard wrote:
> On Wed, May 23, 2012 at 3:03 AM, Kinuko Yasuda wrote:
> Just to make sure, I assume 'the underlying storage' includes memory.
>
> Right. For simple Blobs without a mutable backing store, all of this
> essentially optimizes away.
>
> We shou
Glenn,
On May 22, 2012, at 11:48 AM, Glenn Maynard wrote:
> On Tue, May 22, 2012 at 1:41 AM, Kinuko Yasuda wrote:
> In my understanding WebKit's behavior is querying the metadata / reading the
> content as lazy as possible, partly because the spec was/is ambiguous
> (especially about when the
Glenn:
On May 21, 2012, at 9:44 PM, Glenn Maynard wrote:
> On Mon, May 21, 2012 at 6:05 PM, Eric U wrote:
> According to the latest editor's draft [1], a File object must always
> return an accurate lastModifiedDate if at all possible.
> "On getting, if user agents can make this information ava
On Apr 27, 2012, at 1:28 AM, Anne van Kesteren wrote:
> On Fri, 27 Apr 2012 00:13:42 +0200, Arun Ranganathan
> wrote:
>> The constructor will switch to use ArrayBufferView in lieu of ArrayBuffer,
>> but the read method exposed on FileReader and FileReaderSync will read fil
On Apr 24, 2012, at 7:00 PM, David Herman wrote:
> On Apr 24, 2012, at 3:53 PM, David Herman wrote:
>
>> On Apr 12, 2012, at 2:48 PM, Arun Ranganathan wrote:
>>
>>> I intend to add ArrayBufferView as a parameter to the Blob constructor .
>>
>> Would
> On Mar 30, 2012, at 2:25 PM, ext Eric U wrote:
>
> > On Fri, Mar 30, 2012 at 5:39 AM, Arthur Barstow
> > wrote:
> >> Hi All - the publication of the File API LC was delayed because of
> >> some logistical issues for Arun as well as some additional edits
> >> he intends to make.
> >>
> >> This
> On Thu, Apr 12, 2012 at 12:54 PM, Anne van Kesteren
> wrote:
> > Eric, the plan is to remove that from File Writer, no?
>
> Yes. The next draft I publish will mark it deprecated, and it will
> eventually go away. However, currently at least Gecko and WebKit
> support BlobBuilder, and WebKit d
Ken,
> I'm not sure that adding close() to Transferable is a good idea. Not
> all Transferable types may want to support that explicit operation.
> What about adding close() to Blob, and having the neutering operation
> on Blob be defined to call close() on it?
Specifically, you think this is no
Feras,
In practice, I think this is important enough and manageable enough to include
in the spec., and I'm willing to slow the train down if necessary, but I'd like
to understand a few things first. Below:
- Original Message -
> At TPAC we discussed the ability to deterministically
Eric,
> On Fri, 02 Mar 2012 01:01:55 +0100, Eric U wrote:
> > On Thu, Mar 1, 2012 at 3:16 PM, Arun Ranganathan
> > wrote:
> >> OK, so the change is to ensure that these events are fired
> >> directly,
> >> and not queued, right? I'll make thi
Eric,
> In the readAsText in the latest draft [1] I see that readyState gets
> set to done "When the blob has been read into memory fully".
> I see that elsewhere in the progress notification description, "When
> the data from the blob has been completely read into memory, queue a
> task to fire a
Eric,
> >> > So we could:
> >> > 1. Say not to fire a loadend if onloadend or onabort
>
> Do you mean "if onload, onerror, or onabort..."?
No, actually. I'm looking for the right sequence of steps that results in
abort's loadend not firing if terminated by another read*. Since abort will
f
> On Wed, Feb 29, 2012 at 1:43 PM, Arun Ranganathan
> >> Otherwise, if you start a new read in onabort [8.5.6 step 5],
> >> you'll
> >> still deliver the loadend [8.5.6 step 6].
> >> This contradicts 8.5.9.2.1 "Once a loadstart has been fired, a
On Wed, Feb 29, 2012 at 2:36 PM, Arun Ranganathan < aranganat...@mozilla.com >
wrote:
> > On Tue, Feb 28, 2012 at 6:46 PM, Arun Ranganathan <
> > aranganat...@mozilla.com > wrote:
>
> > > Should the actual UTF-8 encoding algorithm be specified by HTML?
>
FileReader.abort is like a bad penny :)
>
> However, I'm not sure it quite matches the normative text in one
> respect. Where you say [8.5.6 step 4]: "Terminate any steps while
> processing a read method." Does that also terminate the steps
> associated with an abort that terminated the read m
On Tue, Feb 28, 2012 at 6:46 PM, Arun Ranganathan < aranganat...@mozilla.com >
wrote:
> > or use another algorithm with an identical result, and be decoded
> > as UTF-8.
> I think this can be removed. You can always replace algorithms with
> equivalent ones, in any p
On Tue, Feb 28, 2012 at 12:11 AM, Simon Pieters < sim...@opera.com > wrote:
> > I think WebSocket should do the same, for the same reason.
>
> > Have you filed a bug?
>
> (No, not until this conversation moves along a bit further.)
> On Tue, Feb 28, 2012 at 8:26 AM, Jonas Sicking
> wrote:
>
Simon,
Is the relevant part of HTML sufficient to refer to?
http://dev.w3.org/html5/spec/Overview.html#utf-8
> What I can do is procrastinate until we agree that BlobBuilder is
> deprecated, and this is now the problem of the Blob constructor.
> Over
> to you, Arun and Jonas.
>
> On Mon, Se
> On 24.2.2012 20:12, Arun Ranganathan wrote:
> > Bronislav,
> >
> >
> >> I could also go with reverse approach, with createObjectURL being
> >> oneTimeOnly by default
> >> createObjectURL(Blob aBlob, boolean? isPermanent)
> >> instead of cu
Bronislav,
> I could also go with reverse approach, with createObjectURL being
> oneTimeOnly by default
> createObjectURL(Blob aBlob, boolean? isPermanent)
> instead of current
> createObjectURL(Blob aBlob, boolean? isOneTime)
> the fact, that user would have to explicitly specify, that such URL
Anne,
> On Mon, 06 Feb 2012 19:18:35 +0100, Arun Ranganathan
> wrote:
> >> I think per https://www.w3.org/Bugs/Public/show_bug.cgi?id=15359
> >> we
> >> want to let the BOM checking happen before the other
> >> considerations.
> >
> > R
Ms2ger,
Many thanks for the detailed review.
>
> == 1. Introduction ==
>
> > "Binary Large Object" -- a name originally introduced to web APIs
> > in Google Gears
>
> should use an en dash (—, U+2013) instead of two hyphens.
Done.
>
> This paragraph is inconsistent about linking File and
Anne,
> On Thu, 26 Jan 2012 22:57:35 +0100, Arun Ranganathan
> wrote:
> > Few quick questions:
> >
> > 1. Can you review:
> > http://dev.w3.org/2006/webapi/FileAPI/#encoding-determination
>
> I think per https://www.w3.org/Bugs/Public/show_bug.cgi?id=15359
- Original Message -
> On Tuesday, January 10, 2012 12:34 PM, Arun Ranganathan wrote:
> > Greetings Adrian,
> >
> > Sorry for the delay in responding to this email.
> >
> > Strictly speaking, we could remove the Blob Protocol Version (BLV)
&
On Wed, Dec 14, 2011 at 4:40 PM, Ian Hickson < i...@hixie.ch > wrote:
> > (From Glenn Maynard)
>
> > I think it's dangerous to assume that the URL will only be
> > dereferenced
>
> > once. For example, it would mean that the above image would break
> > if
> > the
>
> > user toggled images off
> On 1/26/12 1:21 PM, Arun Ranganathan wrote:
> Yes, this is nicer. There's no way to create a new File object: I
> can't
> set name and lastModifiedDate.
These can't be done, but there is FileSaver/FileWriter).
>
> There's an error in the blob const
Glenn points out that the issues raised in this thread weren't totally taken to
the mat. Once again, sorry for bad nesting in my response:
> > We can certainly talk through some of these issues, though the
> > amount
> > of
>
> > work we'd need to do doesn't go down. Our proposal is a small
> >
(Sorry for top-posting; I'm dealing with a sub-par mail client due to ongoing
mail server issues).
Tab:
You've handsomely made the point to replace the existing optional boolean with
a dictionary (which is what we do for the Blob constructor). I suppose I
thought the dictionary was overkill f
Greetings public-webapps,
I'd like to encourage some review of File API:
http://dev.w3.org/2006/webapi/FileAPI/
You can send comments to this listserv, or file a bug, since this spec. now has
a Bugzilla component.
Here are some notable changes:
1. Blob is now constructable, following discu
On 1/12/12 12:53 PM, Arun Ranganathan wrote:
> > Oh I'm glad to see this one! Is it Blob and File that can be put
> > into
> > IDB? How do I create a new File (with a name field) from a Blob?
>
> > Charles: see the thread on making Blobs constructable -- follow
On Jan 12, 2012, at 6:58 AM, Kyle Huey < m...@kylehuey.com > wrote:
> > On Thu, Jan 12, 2012 at 3:45 PM, Glenn Maynard < gl...@zewt.org >
> > wrote:
>
> > > FYI, I don't think this is clear for File from the spec. It's
> > > even
> > > more important if File objects are stored in History or
> >
Glenn,
Sorry about letting this one get by unanswered -- I was OOTO at the time you
sent it.
>> Questions and thoughts while reading
>> http://dev.w3.org/2006/webapi/FileAPI/#enctype:
>> is this spec actually
>> requiring that every registered encoding be supported?
What's required is that UA
Greetings Adrian,
Sorry for the delay in responding to this email.
Strictly speaking, we could remove the Blob Protocol Version (BLV) [1]. It
isn't returned in getAllResponseHeaders. BLV 's purpose was in case the
protocol changes, and to differentiate between versions. But the protocol is
Art,
I'd be happy with a bugzilla component for File API.
-- A*
- Original Message -
> Hi Brona,
>
> For mostly historical reasons, WebApps' File* specs still use Tracker
> rather than Bugzilla (and IIRC, Arun also uses the list archive as
> well
> as the spec itself to track issues for
- Original Message -
> On Fri, Dec 16, 2011 at 3:13 PM, Michael Nordman
> wrote:
> > There is no requirement for that in the spec/draft, it's useful for
> > our
> > implementation.
>
> I suspect this will be true in Firefox too in due time. So I
> definitely think that we should allow f
- Original Message -
> The current spec requires the opaque string in Blob URLs to be at
> least
> 36 characters in length [1]. Our implementation doesn't currently use
> a
> UUID and the length of the string is shorter than 36 characters. While
> I have no problem with the recommendation t
- Original Message -
> Wouldn't mind a more managed log of API shifts. Any ideas for a very
> simple deprecation journal?
I'd be a fan of this. To date, the only thing I've deprecated (and will
eventually remove) is readAsBinaryString.
>
> On topic: anyone using readAsBinaryString oug
Adrian,
- Original Message -
> At TPAC [1,2] I described our proposal for adding an isReusable flag
> to
> createObjectURL. A common pattern we have seen is the need for a blob
> URL
> for a single use (for example, loading into an element) and then
> revoking the URL. This requires a fa
I'm happy to remove this from the specification. Right now this is marked as
deprecated, which I suppose isn't strong enough discouragement? :)
- Original Message -
> Another topic that came up at TPAC was readAsBinaryString [1]. This
> method
> predates support for typed arrays in the
On 10/14/11 10:11 AM, Charles McCathieNevile wrote:
On Mon, 10 Oct 2011 18:25:42 +0200, Arthur Barstow
wrote:
This is a Call for Consensus to publish a WD of the File API spec
(last published 26-Oct-2010):
Do it...
Thanks for encouragement :). The document is in pub rules format
already
On 8/31/11 4:48 AM, Anne van Kesteren wrote:
It's defined as a single algorithm:
http://dev.w3.org/2006/webapi/FileAPI/#dfn-slice
and cribs from ECMAScript's definition of slice. It's the only host
object with a slice.
It still looks like several independent algorithms to me. There should
On 8/31/11 4:39 AM, Anne van Kesteren wrote:
On Wed, 31 Aug 2011 06:20:58 +0200, Arun Ranganathan
wrote:
Done.
Thanks!
I noticed a few small things:
* HTML5 should be without space
* Progress Events is pointing to a dated version rather than the
latest; Charles is also no longer an
On 8/31/11 4:43 AM, Anne van Kesteren wrote:
On Wed, 31 Aug 2011 06:12:06 +0200, Arun Ranganathan
wrote:
On 8/14/11 5:36 AM, Anne van Kesteren wrote:
I think FileList should talk less about selected files and more
about being a collection or list of File objects. That way it can be
reused in
On 8/31/11 3:49 AM, Anne van Kesteren wrote:
This model should be rephrased a bit to make it more clear what the
requirements are. E.g. I think if you use POST it should not be a MAY
but a MUST that 500 is returned.
Also what are the security errors you can get a 500 for? Are they not
handled
On 10/4/11 2:54 AM, Anne van Kesteren wrote:
On Tue, 04 Oct 2011 00:59:18 +0200, Jonas Sicking
wrote:
Yup. I do wonder if we should introduce a DOMError class which can be
reused in various cases which need APIs like this. IndexedDB could
also use it and I seem to recall that HTML5 does too.
On 10/3/11 6:59 PM, Jonas Sicking wrote:
On Mon, Oct 3, 2011 at 3:35 PM, Arun Ranganathan wrote:
On 10/3/11 4:59 PM, Jonas Sicking wrote:
On Mon, Oct 3, 2011 at 11:51 AM, Arun Ranganathan
wrote:
On 9/30/11 9:46 PM, Adrian Bateman wrote:
Hi Arun,
Thanks for the follow-up - you beat me to
On 10/3/11 4:59 PM, Jonas Sicking wrote:
On Mon, Oct 3, 2011 at 11:51 AM, Arun Ranganathan wrote:
On 9/30/11 9:46 PM, Adrian Bateman wrote:
Hi Arun,
Thanks for the follow-up - you beat me to it. We've been reviewing this in
the context of the other specs and, as Israel outlined for Inde
On 10/2/11 7:38 AM, Marcos Caceres wrote:
On Saturday, 1 October 2011 at 08:15, Anne van Kesteren wrote:
On Sat, 01 Oct 2011 02:56:55 +0200, Israel Hileriomailto:isra...@microsoft.com)>
wrote:
On Friday, September 30, 2011 12:23 AM, Anne van Kesteren wrote:
Actually, given
http://dvcs.w3.or
On 9/30/11 11:14 AM, Anne van Kesteren wrote:
On Thu, 29 Sep 2011 23:17:21 +0200, Eric U wrote:
I think that works; #2 will be especially important.
However, if I read this right, we *don't* have the invariant that a
loadstart will always have a loadend.
Now that Anne's explained XHR2's model,
On 9/30/11 9:46 PM, Adrian Bateman wrote:
Hi Arun,
Thanks for the follow-up - you beat me to it. We've been reviewing this in
the context of the other specs and, as Israel outlined for IndexedDB, we're
happy with the new WebIDL approach.
I think we should go ahead and migrate the File API excep
On 10/1/11 4:59 AM, Ms2ger wrote:
Hi Jonas, Arun
As described in bug 13433 [1], the type of event handler IDL
attributes should be "[TreatNonCallableAsNull] Function?". Could you
change File API accordingly?
Thanks
Ms2ger
[1] http://www.w3.org/Bugs/Public/show_bug.cgi?id=13433
Done.
-- A
On 9/30/11 11:14 AM, Anne van Kesteren wrote:
On Thu, 29 Sep 2011 23:17:21 +0200, Eric U wrote:
I think that works; #2 will be especially important.
However, if I read this right, we *don't* have the invariant that a
loadstart will always have a loadend.
Now that Anne's explained XHR2's model,
On 6/6/11 4:36 PM, Adrian Bateman wrote:
On Monday, June 06, 2011 5:56 AM, Arthur Barstow wrote:
Hi Arun, Jonas, All,
The last publication of the File API spec [ED] was last October so it
would be good to publish a new Working Draft in w3.org/TR/.
Since Tracker shows 0 bugs for the spec [Track
On 9/21/11 8:07 PM, Eric U wrote:
Update: I have made the changes to FileWriter/FileSaver's event
sequences; they now match FileReader.
That's not to say it won't change pending discussion, but FileWriter
should continue to match FileReader whatever else happens.
Eric
Eric:
After readin
On 9/29/11 12:29 PM, Anne van Kesteren wrote:
On Thu, 29 Sep 2011 01:19:53 +0200, Arun Ranganathan
wrote:
On 8/31/11 3:45 AM, Anne van Kesteren wrote:
Yeah sure, every URI is an IRI, but that is not what I am asking.
I'm sorry, I think I'm not understanding you very clearly :(
On 8/31/11 3:45 AM, Anne van Kesteren wrote:
On Wed, 31 Aug 2011 06:22:05 +0200, Arun Ranganathan
wrote:
On 8/14/11 6:00 AM, Anne van Kesteren wrote:
Why can you not use characters legally allowed in IRIs?
You can; they have to be escaped.
Yeah sure, every URI is an IRI, but that is not
On 7/12/11 8:20 PM, Eli Grey wrote:
Shouldn't the algorithm for determining encoding for
FileReader.readAsText() take in account the type property's charset
parameter, if it exists? (e.g. a blob.type of
"text/plain;charset=UTF-8")
Greetings Eli,
Apologies for the long delay in response time.
On 9/27/11 4:13 PM, Eric U wrote:
On Mon, Sep 26, 2011 at 2:38 PM, Arthur Barstow wrote:
The upcoming TPAC meeting (Oct 31 - Nov 01) provides an opportunity for
joint WG meetings and lots of informal sharing. As such, some groups make
spec publications right before TPAC.
Note there is a 2-week
On 8/14/11 6:00 AM, Anne van Kesteren wrote:
Why can you not use characters legally allowed in IRIs?
You can; they have to be escaped.
The bit on UUID should be turned into a note if it is non-normative
instead of saying it is non-normative.
Done (with an Appendix).
-- A*
On 8/14/11 5:58 AM, Anne van Kesteren wrote:
For the HTML dependency it seems this specification depends on event
handler attributes as well.
The Typed Arrays specification should either become a normal
dependency or you need to introduce different conformance classes.
Currently it is contrad
On 8/14/11 5:53 AM, Anne van Kesteren wrote:
It is not clear from the specification when the asynchronous methods
return. This should be stated.
Done.
http://dev.w3.org/2006/webapi/FileAPI/#reading-a-file (and see each read
method definition).
-- A*
On 8/14/11 5:51 AM, Anne van Kesteren wrote:
The first step says SHOULD but the whole algorithm is a MUST. That
does not work. I also do not see why it is a SHOULD.
The algorithm and the preceding paragraph also seem to have a circular
dependency. Please turn it into a single algorithm instead
On 8/14/11 5:46 AM, Anne van Kesteren wrote:
Is it too late to change the constants to simple string values?
I think the implementation bird has flown here :(
-- A*
On 8/14/11 5:45 AM, Anne van Kesteren wrote:
I think we should add a warning to the document that the exceptions
will change. How they change depends on the outcome of the web
platform exceptions discussions.
Done.
http://dev.w3.org/2006/webapi/FileAPI/#ErrorAndException
-- A*
On 8/14/11 5:42 AM, Anne van Kesteren wrote:
Why does the slice() method use [TreatUndefinedAs=EmptyString]? Can it
not just use the normal default handling? Also, if you do indeed want
to use that saying "If the contentType parameter is undefined, let
relativeContentType be set to the empty st
On 8/14/11 5:36 AM, Anne van Kesteren wrote:
FileList does not follow the requirements from Web IDL:
http://dev.w3.org/2006/webapi/WebIDL/#idl-indexed-properties
Specifically you mean:
1. FileList's WebID definition should show that the getter returns a
nullable type AND
2. Supported propert
On 8/15/11 12:27 PM, Anne van Kesteren wrote:
On Mon, 15 Aug 2011 18:06:30 +0200, Arun Ranganathan
wrote:
On 8/14/11 9:00 AM, Anne van Kesteren wrote:
Why can you not use characters legally allowed in IRIs?
Are you referring to the "permissible charset" for ranges of
charact
On 8/14/11 8:58 AM, Anne van Kesteren wrote:
For the HTML dependency it seems this specification depends on event
handler attributes as well.
Agreed.
The Typed Arrays specification should either become a normal
dependency or you need to introduce different conformance classes.
Currently it
On 8/14/11 9:00 AM, Anne van Kesteren wrote:
Why can you not use characters legally allowed in IRIs?
Are you referring to the "permissible charset" for ranges of characters
or the condition disallowing reserved characters? I've only omitted the
ones that should be percent-encoded. Honestly,
Greetings WebApps WG,
The latest editor's draft of the File API can be found here:
http://dev.w3.org/2006/webapi/FileAPI/
Changes are based on feedback on this listserv, as well as the URI
listserv (e.g. [1][2][3]).
Chrome team: some of the feedback is to more rigorously define the
opaqueSt
On 8/5/11 2:19 PM, Philippe Le Hegaret wrote:
On Fri, 2011-08-05 at 13:41 -0400, Arun Ranganathan wrote:
On 8/5/11 11:52 AM, Philippe Le Hegaret wrote:
On Fri, 2011-08-05 at 17:18 +0200, Marcos Caceres wrote:
Again, what are the reasons to link to the WHATWG HTML version?
If there is
On 8/5/11 11:52 AM, Philippe Le Hegaret wrote:
On Fri, 2011-08-05 at 17:18 +0200, Marcos Caceres wrote:
Again, what are the reasons to link to the WHATWG HTML version?
If there is something you need that is not in the W3C spec, then it seems like
a valid reason (e.g., PeerConnection API or som
dyState to DONE, result to null, and process the error
steps? Any thoughts?
Arun Ranganathan:
My thoughts are that this should be an OperationNotAllowedException,
and that this should be better defined.
IMHO WebIDL doesn't touch on what happens when a method within a
given API is called
On 6/30/11 6:01 PM, Gregg Tavares (wrk) wrote:
On Tue, Jun 21, 2011 at 10:17 AM, Arun Ranganathan <mailto:a...@mozilla.com>> wrote:
Sorry if these have all been discussed before. I just read the
File API for the first time and 2 random questions popped in my
head.
On 7/6/11 7:54 PM, Adrian Bateman wrote:
http://dev.w3.org/2006/webapi/FileAPI/#reading-a-file
What is the expected behaviour for FileReader.readAsXXX(null)? Currently
I think both IE10 and Chrome fail silently and there are no events fired
whereas Firefox appears to throw an internal NS_ERROR_I
Greetings Adam,
Ian, I wish I knew that earlier when I originally posted the idea,
there was lots of discussion and good ideas but then it suddenly
dropped of the face of the earth. Essentially I am fowarding this
suggestion to public-webapps@w3.org on the basis as apparently most
discussion of
Sorry if these have all been discussed before. I just read the File
API for the first time and 2 random questions popped in my head.
1) If I'm using readAsText with a particular encoding and the data in
the file is not actually in that encoding such that code points in the
file can not be mapp
Hi Arun, Jonas, All,
The last publication of the File API spec [ED] was last October so it
would be good to publish a new Working Draft in w3.org/TR/.
Since Tracker shows 0 bugs for the spec [Tracker] and the ED does not
appear to identify any open issues, does the spec meet the Last Call
Wo
Le lundi 06 juin 2011 à 08:55 -0400, Arthur Barstow a écrit :
The last publication of the File API spec [ED] was last October so it
would be good to publish a new Working Draft in w3.org/TR/.
Since Tracker shows 0 bugs for the spec [Tracker] and the ED does not
appear to identify any open issues
Web Applications Working Group Issue Tracker:
FileError [1] and FileException [2] both define a DOMString attribute
called name that contains the name of the error/exception constant as
a string. Since this is not a useful "human readable" error message,
and developers should be encouraged to wri
which the spec no longer says to do. I'm inclined to
leave ABORT_ERR around, but right now, it never really gets used.
-- A*
Thanks,
Jian
On Wed, May 11, 2011 at 3:49 PM, Arun Ranganathan <mailto:a...@mozilla.com>> wrote:
The Editor's Draft of the FileAPI --
htt
On 6/7/11 5:04 PM, Jonas Sicking wrote:
On Tue, Jun 7, 2011 at 11:51 AM, Jian Li wrote:
On Tue, Jun 7, 2011 at 11:23 AM, Jonas Sicking wrote:
On Tue, Jun 7, 2011 at 10:43 AM, Jian Li wrote:
I have a couple questions regarding abort behavior.
If the reading is completed and the loadend eve
On 6/1/11 5:42 PM, Adam Barth wrote:
I've been implementing bits and pieces in WebKit. If there's interest
from other implementors, I'm happy to work on the document in the W3C
process.
I'm definitely interested in seeing this become a rec-track document.
Ad-hoc pieces of this live in other
On 5/23/11 6:14 PM, Arun Ranganathan wrote:
On 5/23/11 1:20 PM, Kyle Huey wrote:
To close the loop a bit here, Firefox 6 will make the change to
FileReader.abort()'s throwing behavior agreed upon here.
(https://bugzilla.mozilla.org/show_bug.cgi?id=657964)
We have not changed the timi
On 5/23/11 1:20 PM, Kyle Huey wrote:
To close the loop a bit here, Firefox 6 will make the change to
FileReader.abort()'s throwing behavior agreed upon here.
(https://bugzilla.mozilla.org/show_bug.cgi?id=657964)
We have not changed the timing of the events, which are still
dispatched synchro
The Editor's Draft of the FileAPI --
http://dev.w3.org/2006/webapi/FileAPI/ -- has had some updates. These
are the notable changes:
1. Blob.slice behavior has changed to more closely match
String.prototype.slice from ECMAScript (and Array.prototype.slice
semantically). I think we're the fir
On 4/14/11 5:22 AM, Jonas Sicking wrote:
On Thu, Apr 14, 2011 at 2:16 AM, James Graham wrote:
On 04/14/2011 03:04 AM, Jonas Sicking wrote:
It would be nice to hear from someone at Opera about their willingness to
commit to this change
as well.
As a general point we think that making breaking
On 4/18/11 3:55 PM, Adrian Bateman wrote:
On Monday, April 18, 2011 12:04 PM, Jonas Sicking wrote:
On Mon, Apr 18, 2011 at 9:02 AM, Adrian Bateman
wrote:
On Friday, April 15, 2011 2:41 PM, Jonas Sicking wrote:
Yes. I.e. the semantics of readAsX is basically:
readAsX(...) {
if (requestInPro
On 4/15/11 6:29 PM, Aryeh Gregor wrote:
On Wed, Apr 13, 2011 at 4:35 PM, Robert Ginda wrote:
* The FileError object is a bit awkward to work with. I found that I
frequently had every reason to expect my calls to succeed (because
they were a follow-on to something that already succeeded), but I
On 4/15/11 2:57 PM, Adrian Bateman wrote:
On Tuesday, April 12, 2011 12:08 PM, Jonas Sicking wrote:
FileReader is extremely similar to XMLHttpRequest. The main difference
is in how you initiate the request (.open/.send vs. .readAsX). This
similarity is even getting stronger now that XHR gets .re
On 4/12/11 6:04 PM, Dmitry Titov wrote:
I think Glenn was asking how would the developers detect the new
behavior of slice() if we decide to change it and there will be 2
versions of behavior around with the same method name...
You're right -- silly me! Glenn's usefully trying to detect one s
On 4/12/11 4:45 PM, Charles Pritchard wrote:
We're using ArrayBuffer... It's been through a few changes of its own
relating to slice.
I think they just went the route of renaming the method.
To be clear, here you're referring to the *.subarray method of TypedArray:
http://www.khronos.org/reg
On 4/12/11 5:27 PM, Glenn Maynard wrote:
On Tue, Apr 12, 2011 at 2:24 PM, Jonas Sicking wrote:
File.slice is currently shipped by Chrome and Firefox 4. I would be
fine with fixing this in Firefox 4.0.1, however that only makes sense
if the chrome folks are fine with fixing it in the
On 4/11/11 1:39 PM, Adrian Bateman wrote:
On Monday, April 11, 2011 10:23 AM, Eric Uhrhane wrote:
On Mon, Apr 11, 2011 at 9:33 AM, Arun Ranganathan wrote:
In general, I'm averse to throwing, since I think it puts an additional
burden on the developer (to catch, for example).
I don'
On 4/12/11 2:24 PM, Jonas Sicking wrote:
Hi All,
It was recently (yesterday) pointed out to me that we let a bad
spec-bug slip through for File.slice. It doesn't match the argument
semantics of Array.slice which can be very confusing for developers.
In Array.slice the second argument is the ind
On 4/11/11 1:04 PM, Glenn Maynard wrote:
On Mon, Apr 11, 2011 at 12:33 PM, Arun Ranganathan <mailto:a...@mozilla.com>> wrote:
In general, I'm averse to throwing, since I think it puts an
additional burden on the developer (to catch, for example).
Only if the develope
On 4/11/11 12:05 PM, Adrian Bateman wrote:
On Monday, April 11, 2011 8:28 AM, Arun Ranganathan wrote:
On 3/31/11 6:12 PM, Eric Uhrhane wrote:
I think it's cleaner and simpler just to throw. FileReader and XHR
are already different enough that a bit more, as long as it's a
On 3/31/11 6:12 PM, Eric Uhrhane wrote:
On Thu, Mar 31, 2011 at 2:55 PM, Adrian Bateman wrote:
On Thursday, March 31, 2011 10:19 AM, Arun Ranganathan wrote:
On 3/30/11 2:01 PM, Eric Uhrhane wrote:
On Mon, Mar 28, 2011 at 5:37 PM, Adrian Bateman
wrote:
Is there a reason for the current spec
On 4/11/11 9:38 AM, Arthur Barstow wrote:
Hi Arun, Jonas - what is the status/plan for the File API spec?
What remains to be done before the spec is "LC ready"?
Art:
A few things need to be done:
1. There continue to be a few spec. nits about multiple read calls;
these have to be addressed.
Eric, Adrian,
On 3/30/11 2:01 PM, Eric Uhrhane wrote:
On Mon, Mar 28, 2011 at 5:37 PM, Adrian Bateman wrote:
As we continue to experiment with the File API, I'm trying to understand the
rationale for the Multiple Reads section:
http://dev.w3.org/2006/webapi/FileAPI/#MultipleReads
The spec sa
101 - 200 of 351 matches
Mail list logo
