> On Wed, Aug 17, 2016 at 11:38:59, Marijn Kruisselbrink wrote:
> Sorry about that. Somehow that PR slipped through the cracks. I've commented
> on the PR.
>
> Anybody knows what the deal is with the ipr check? What makes it fail, and if
> it fails who is supposed to do what to not make it fail?
wrote:
>> > Hi,
>> >
>> > I have a PR on GitHub regarding some issues of wording in current File
>> API spec: https://github.com/w3c/FileAPI/pull/42
>> > , but nobody ever responded me there.
>> > I wonder if I should discuss the patch somewhere els
rent File
> API spec: https://github.com/w3c/FileAPI/pull/42
> > , but nobody ever responded me there.
> > I wonder if I should discuss the patch somewhere else?
>
> It seems that no one has touched that API for about 8 months.
>
> Marijn, are you still editing that document? I guess Jonas won't be,
> but not sure about Arun.
>
>
On August 16, 2016 at 6:31:31 PM, Zhen Zhang (izgz...@gmail.com) wrote:
> Hi,
>
> I have a PR on GitHub regarding some issues of wording in current File API
> spec: https://github.com/w3c/FileAPI/pull/42
> , but nobody ever responded me there.
> I wonder if I should discuss t
Hi,
I have a PR on GitHub regarding some issues of wording in current File API
spec: https://github.com/w3c/FileAPI/pull/42
<https://github.com/w3c/FileAPI/pull/42>, but nobody ever responded me there.
I wonder if I should discuss the patch somewhere else?
Thanks you,
- Zhen
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24732
Aryeh Gregor changed:
What|Removed |Added
Status|NEW |RESOLVED
a mechanism to trigger
programmatic downloads to the underlying OS filesystem.
But upon reflection, although FileAPI itself hasn’t provided any API surface
for this, the recently finished HTML specification has given us something
useful, but not implemented widely yet:
http://www.w3.org/TR/html5
On Oct 22, 2014, at 8:05 AM, Arthur Barstow art.bars...@gmail.com wrote:
* File API: Arun and Jonas; which v1 bugs are blocking a new LC; what are
next steps; timeline for LC.
Arun, Jonas,
Please see the above and respond accordingly. I am especially interested in
the File API status
On 10/11/14 10:43 AM, Arthur Barstow wrote:
If you are an Editor and you did not register for the meeting please
note:
a) If you can join the meeting via the teleconf bridge, please: 1) add
your spec to the Potential Topics list and identify high priority
discussion points; 2) plan to
Status:
The specs are clearly dead; it's just been way down on my
priority list to do anything about it. We should funnel it off to be
a Note [or whatever the proper procedure is--Art?].
Eric
On 4/2/14 12:36 PM, ext Eric U wrote:
Status:
The specs are clearly dead; it's just been way down on my
priority list to do anything about it. We should funnel it off to be
a Note [or whatever the proper procedure is--Art?].
Thanks for the quick reply Eric. When a group agrees to stop
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24732
Bug ID: 24732
Summary: Remove DOMError from FileAPI
Product: WebAppsWG
Version: unspecified
Hardware: PC
OS: All
Status: NEW
Severity: normal
Art,
All LC commentary (http://www.w3.org/wiki/Webapps/LCWD-FileAPI-20130912) has
been addressed and I think the draft is ready to be published as CR status.
The draft is: http://dev.w3.org/2006/webapi/FileAPI/
-- A*
On Nov 8, 2013, at 10:15 AM, Arun Ranganathan wrote:
Hi Art,
On Nov 7
in the WHATWG URL spec, in lieu of ABNFs.
If you provide a dial-in on the day that you discuss File + FileSystem, I can
try and dial in, but this depends on time. There will be others present from
Mozilla :) The LC commentary is tracked at
http://www.w3.org/wiki/Webapps/LCWD-FileAPI-20130912
. I am especially interested in
whether or not you consider any of the bug fixes you applied as
substantive and/or add a new feature (which would require a new LC).
-Thanks, ArtB
[1] http://www.w3.org/wiki/Webapps/LCWD-FileAPI-20130912
On 9/12/13 10:39 AM, ext Arthur Barstow wrote:
[ Bcc
Hi,
For the purposes of tracking your comments for the September 12 File API
Last Call Working Draft, please let us know if Arun's reply is
satisfactory or not. In the absence of a reply from you by November 7,
we will assume Arun's reply is OK with you.
-Thanks, ArtB
On 10/23/13 6:04 PM,
Note that all LC Commentary, including that sent on this listserv, is tracked
here:
http://www.w3.org/wiki/Webapps/LCWD-FileAPI-20130912
-- A*
On Oct 31, 2013, at 9:12 AM, Arthur Barstow wrote:
Hi,
For the purposes of tracking your comments for the September 12 File API Last
Call Working
7.2 Interface File:
-add creationDate property
-add size property
-If the last modification date and time are not known, the attribute
must return an empty string
8.3. Event Handler Attributes
-add onNotfounderror event handler
-add onReaderror event handler
-add onSecurityerror event handler
Hi there!
On Oct 23, 2013, at 12:32 PM, psweatte wrote:
7.2 Interface File:
-add creationDate property
Thanks for your feedback. *Most* filesystems don't really have a creation
time. While Windows does, Unix-style OS return the *change time or last
modified time. Since we want fidelity
On Oct 3, 2013, at 6:35 PM, Brian Matthews (brmatthe) wrote:
First is the status bar display for anchors while hovering over them. As
expected, it's the blob URL. While this is completely correct and exactly
what I'd expect, I'm not sure how useful it is. For an anchor with a normal
URL,
specific for the spec (http://www.w3.org/TR/FileAPI/) to comment on, but I
thought I'd ask here and see if there's something I'm missing, and make a
suggestion.
First is the status bar display for anchors while hovering over them. As
expected, it's the blob URL. While this is completely
of
things that seem like they could work better. They might be things that are
too user agent specific for the spec (http://www.w3.org/TR/FileAPI/) to
comment on, but I thought I'd ask here and see if there's something I'm
missing, and make a suggestion.
(FYI, the link you want is http://dev.w3.org
, but there are a couple of
things that seem like they could work better. They might be things that are
too user agent specific for the spec (http://www.w3.org/TR/FileAPI/) to
comment on, but I thought I'd ask here and see if there's something I'm
missing, and make a suggestion.
I think
On 10/4/13 10:48 AM, Kyle Huey wrote:
If a File object (which has a name) is used instead of a Blob I think we
should treat it as if something like Content-Disposition:
filename=$file.name http://file.name was specified in an HTTP
request.
Gecko does, because a bunch of servers send it. See
, but there are a couple of things that
seem like they could work better. They might be things that are too user agent
specific for the spec (http://www.w3.org/TR/FileAPI/) to comment on, but I
thought I'd ask here and see if there's something I'm missing, and make a
suggestion.
(FYI, the link you
On 10/4/13 7:48 AM, Kyle Huey m...@kylehuey.commailto:m...@kylehuey.com
wrote:
Second, and related, is what happens when someone saves an image or target of a
link. In both cases with normal URLs, there's a name component and the user
agent can use that as the name of the resulting file, or
On 10/4/13 7:54 AM, Boris Zbarsky bzbar...@mit.edu wrote:
On 10/4/13 10:48 AM, Kyle Huey wrote:
If a File object (which has a name) is used instead of a Blob I think we
should treat it as if something like Content-Disposition:
filename=$file.name http://file.name was specified in an HTTP
[I tacked this on to another question but should have asked it separately, so
here it is.]
In the File API spec, section 8.5.6, step 1 starts Fire a progress event
called error. Set the error attribute;. Doesn't firing an event call the event
handler immediately (synchronously)? I followed
I agree, the available libraries that currently exists not only are
slow compared to native code (I don't know of anyone that use the
trick used on the demos scene of canvas.getasbytestring() ) and to
speed up things they use webworkers, so they are difficult to use from
file:// scheme pages.
We've had a few conversations pop up about exposing deflate/inflate to
the webapps environment.
Years of them (more recently May 2013).
Packaging a zip file is very simple in JS, it's just the inflate/deflate
code that's a trudge.
We all know the benefits of compressing JSON and XML over the
Hello,
I have a few suggestions (for Blob URL) for you, because in my experience, they
should be part of the specification.
*The events:*
Currently it is not possible not to know if a Blob URL has been loaded by
the browser, whether it is an image, a file download, etc..
For example,
to take a list of values in an operation argument, and you don't want to
keep a reference to a platform array object, you should use a sequence.
Done. http://dev.w3.org/2006/webapi/FileAPI/#dfn-Blob
-- A*
Arun Ranganathan:
I've pinged heycam to see if this is a proper use of the sequence type. I'm
not sure it allows for such a variation in parameters.
I agree with Boris, it makes sense to use sequence here. Whenever you
just want to take a list of values in an operation argument, and you
In particular, a Blob represents immutable binary data. That means that
it has to copy the input anyway. Given that, it doesn't make sense to
pass the input by reference if the caller _does_ happen to have an
WebIDL array object.
But worse yet, actual real-life callers call this with JS
On 9/9/12 12:13 PM, Glenn Maynard wrote:
In particular, a Blob represents immutable binary data. That means
that it has to copy the input anyway. Given that, it doesn't make
sense to pass the input by reference if the caller _does_ happen to
have an WebIDL array object.
That
BERNARD
Le 12/08/2012 21:23, Jonas Sicking a écrit :
On Sun, Aug 12, 2012 at 2:56 AM, Benjamin BERNARD
benjamin.bern...@benvii.com wrote:
Hi,
I was developing an offline music web App when I discover that is no
Content-length header specified here :
http://www.w3.org/TR/FileAPI
On Sun, Aug 12, 2012 at 2:56 AM, Benjamin BERNARD
benjamin.bern...@benvii.com wrote:
Hi,
I was developing an offline music web App when I discover that is no
Content-length header specified here :
http://www.w3.org/TR/FileAPI/#ProtocolExamples
So when you play an audio/video file stored
Hi,
It looks like IE10 supports File.slice() using the new spec.
Is it safe to use the new File.slice() spec, or should IE be using a vendor
prefix like Firefox and Chrome are currently doing.
Thanks,
Andy
https://www.w3.org/Bugs/Public/show_bug.cgi?id=17277
Ms2ger ms2...@gmail.com changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
https://www.w3.org/Bugs/Public/show_bug.cgi?id=17277
Summary: [FileAPI] It have no clear behavior about negative
index of FileList.item
Product: WebAppsWG
Version: unspecified
Platform: PC
OS/Version: All
Status
On Tue, Feb 14, 2012 at 5:56 PM, Jonas Sicking jo...@sicking.cc wrote:
On Thu, Feb 2, 2012 at 4:40 PM, Ian Hickson i...@hixie.ch wrote:
Anything's possible, but I think the pain here would far outweigh the
benefits. There would be some really hard questions to answer, too (e.g.
what would
On 27.3.2012 11:43, Robert O'Callahan wrote:
On Tue, Feb 14, 2012 at 5:56 PM, Jonas Sicking jo...@sicking.cc wrote:
On Thu, Feb 2, 2012 at 4:40 PM, Ian Hickson i...@hixie.ch
mailto:i...@hixie.ch wrote:
Anything's possible, but I think the pain here would far
outweigh the
On Thu, 08 Mar 2012 00:58:02 +0100, Feras Moussa fer...@microsoft.com
wrote:
In the case where close was called on a Blob that is being used in a
pending request, then the request should be canceled. The expected
result is the same as if abort() was called.
It seems very weird that invoking
On Wed, Mar 7, 2012 at 5:58 PM, Feras Moussa fer...@microsoft.com wrote:
In the case where close was called on a Blob that is being used in a
pending request, then the request should be canceled. The expected
result is the same as if abort() was called.
This would complicate every API that
On Wed, 07 Mar 2012 02:12:39 +0100, Feras Moussa fer...@microsoft.com
wrote:
xhr.send(blob);
blob.close(); // method name TBD
In our implementation, this case would fail. We think this is reasonable
because the
need for having a close() method is to allow deterministic release of
the
On Tue, Mar 6, 2012 at 6:29 PM, Glenn Maynard gl...@zewt.org wrote:
On Tue, Mar 6, 2012 at 4:24 PM, Michael Nordman micha...@google.com wrote:
You can always call close() yourself, but Blob.close() should use the
neuter mechanism already there, not make up a new one.
Blobs aren't
On Wed, Mar 7, 2012 at 11:38 AM, Kenneth Russell k...@google.com wrote:
On Tue, Mar 6, 2012 at 6:29 PM, Glenn Maynard gl...@zewt.org wrote:
On Tue, Mar 6, 2012 at 4:24 PM, Michael Nordman micha...@google.com wrote:
You can always call close() yourself, but Blob.close() should use the
neuter
On Mar 7, 2012, at 11:38 AM, Kenneth Russell k...@google.com wrote:
On Tue, Mar 6, 2012 at 6:29 PM, Glenn Maynard gl...@zewt.org wrote:
On Tue, Mar 6, 2012 at 4:24 PM, Michael Nordman micha...@google.com wrote:
You can always call close() yourself, but Blob.close() should use the
neuter
On Tue, Mar 6, 2012 at 1:18 PM, Kenneth Russell k...@google.com wrote:
On Tue, Mar 6, 2012 at 12:04 PM, Greg Billock gbill...@google.com wrote:
On Mon, Mar 5, 2012 at 6:46 PM, Charles Pritchard ch...@jumis.com wrote:
On 3/5/2012 5:56 PM, Glenn Maynard wrote:
On Mon, Mar 5, 2012 at 7:04 PM,
On Wed, Mar 7, 2012 at 12:02 PM, Charles Pritchard ch...@jumis.com wrote:
On Mar 7, 2012, at 11:38 AM, Kenneth Russell k...@google.com wrote:
On Tue, Mar 6, 2012 at 6:29 PM, Glenn Maynard gl...@zewt.org wrote:
On Tue, Mar 6, 2012 at 4:24 PM, Michael Nordman micha...@google.com wrote:
You
On 3/7/12 12:34 PM, Kenneth Russell wrote:
On Wed, Mar 7, 2012 at 12:02 PM, Charles Pritchardch...@jumis.com wrote:
On Mar 7, 2012, at 11:38 AM, Kenneth Russellk...@google.com wrote:
I believe that we should fix the immediate problem and add a close()
method to Blob. I'm not in favor of
On Wed, Mar 7, 2012 at 1:00 PM, Charles Pritchard ch...@jumis.com wrote:
On 3/7/12 12:34 PM, Kenneth Russell wrote:
On Wed, Mar 7, 2012 at 12:02 PM, Charles Pritchardch...@jumis.com
wrote:
On Mar 7, 2012, at 11:38 AM, Kenneth Russellk...@google.com wrote:
I believe that we should fix the
On Tue, Mar 6, 2012 at 5:12 PM, Feras Moussa fer...@microsoft.com wrote:
From: Arun Ranganathan [mailto:aranganat...@mozilla.com]
Sent: Tuesday, March 06, 2012 1:27 PM
To: Feras Moussa
Cc: Adrian Bateman; public-webapps@w3.org; Ian Hickson; Anne van Kesteren
Subject: Re: [FileAPI
Then let's try this again.
var a = new Image();
a.onerror = function() { console.log(Oh no, my parent was neutered!); };
a.src = URL.createObjectURL(blob); blob.close();
Is that error going to hit?
I documented this in my proposal, but in this case the URI would have
been minted prior to
-Original Message-
From: Anne van Kesteren [mailto:ann...@opera.com]
Sent: Wednesday, March 07, 2012 12:49 AM
To: Arun Ranganathan; Feras Moussa
Cc: Adrian Bateman; public-webapps@w3.org; Ian Hickson
Subject: Re: [FileAPI] Deterministic release of Blob proposal
On Wed, 07 Mar 2012
On 3/7/12 3:56 PM, Feras Moussa wrote:
Then let's try this again.
var a = new Image();
a.onerror = function() { console.log(Oh no, my parent was neutered!); };
a.src = URL.createObjectURL(blob); blob.close();
Is that error going to hit?
until it has been revoked, so in your example onerror
On Mon, Mar 5, 2012 at 6:46 PM, Charles Pritchard ch...@jumis.com wrote:
On 3/5/2012 5:56 PM, Glenn Maynard wrote:
On Mon, Mar 5, 2012 at 7:04 PM, Charles Pritchard ch...@jumis.com wrote:
Do you see old behavior working something like the following?
var blob = new Blob(my new big blob);
After a brief internal discussion, we like the idea over in Chrome-land.
Let's make sure that we carefully spec out the edge cases, though.
See below for some.
On Fri, Mar 2, 2012 at 4:54 PM, Feras Moussa fer...@microsoft.com wrote:
At TPAC we discussed the ability to deterministically close
It seems like this may be setting up a pattern for other dom objects which
are large (like video/audio).
When applied in this context, is close still a good verb for them?
video.close();
dave
PS I'm trying to not bikeshed too badly by avoiding a new name suggestion
and allowing for the fact
On Tue, Mar 6, 2012 at 12:04 PM, Greg Billock gbill...@google.com wrote:
On Mon, Mar 5, 2012 at 6:46 PM, Charles Pritchard ch...@jumis.com wrote:
On 3/5/2012 5:56 PM, Glenn Maynard wrote:
On Mon, Mar 5, 2012 at 7:04 PM, Charles Pritchard ch...@jumis.com wrote:
Do you see old behavior working
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
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 not
Sounds like there's a good case for an explicit blob.close() method
independent of 'transferable'. Separately defining blobs to be
transferrable feels like an unneeded complexity. A caller wishing to
neuter after sending can explicit call .close() rather than relying on
more obscure artifacts of
On Tue, Mar 6, 2012 at 3:18 PM, Kenneth Russell k...@google.com wrote:
A change like this would be feasible as long as it doesn't break
compatibility. In other words, the current Transferable array would
still need to be supported, but Transferable instances (or perhaps
instances of some other
(I wish people wouldn't split threads.)
On Tue, Mar 6, 2012 at 2:29 PM, Eric U er...@google.com wrote:
What about:
XHR.send(blob);
blob.close();
This is the same as:
XHR.send(arrayBuffer);
postMessage({foo: arrayBuffer}, [arrayBuffer]);
which you can already do. Both of
Separately defining blobs to be transferrable feels like an unneeded
complexity. A caller wishing to
neuter after sending can explicit call .close() rather than relying on
more obscure artifacts of having also put the 'blob' in a
'transferrable' array.
You can always call close() yourself,
On Tue, Mar 6, 2012 at 1:31 PM, Arun Ranganathan
aranganat...@mozilla.com wrote:
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 Mar 6, 2012, at 2:25 PM, Kenneth Russell k...@google.com wrote:
On Tue, Mar 6, 2012 at 1:31 PM, Arun Ranganathan
aranganat...@mozilla.com wrote:
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.
From: Arun Ranganathan [mailto:aranganat...@mozilla.com]
Sent: Tuesday, March 06, 2012 1:27 PM
To: Feras Moussa
Cc: Adrian Bateman; public-webapps@w3.org; Ian Hickson; Anne van Kesteren
Subject: Re: [FileAPI] Deterministic release of Blob proposal
Feras,
In practice, I think
clones, was: Re: [FileAPI]
Deterministic release of Blob proposal
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
On 3/6/12 5:12 PM, Feras Moussa wrote:
frameRef.src = URL.createObjectURL(blob);
blob.close() // method name TBD
In my opinion, the first (using xhr) should succeed. In the second,
frameRef.src works,
but subsequent attempts to mint a Blob URI for the same 'blob' resource
fail.
On Tue, Mar 6, 2012 at 4:24 PM, Michael Nordman micha...@google.com wrote:
You can always call close() yourself, but Blob.close() should use the
neuter mechanism already there, not make up a new one.
Blobs aren't transferable, there is no existing mechanism that applies
to them. Adding a
Feras - this seems kinda' late, especially since the two-week pre-LC
comment period for File API ended Feb 24.
Is this a feature that can be postponed to v.next?
On 3/2/12 7:54 PM, ext Feras Moussa wrote:
At TPAC we discussed the ability to deterministically close blobs with
a few
others.
extensive use of the APIs.
-Original Message-
From: Arthur Barstow [mailto:art.bars...@nokia.com]
Sent: Monday, March 05, 2012 12:52 PM
To: Feras Moussa; Arun Ranganathan; Jonas Sicking
Cc: public-webapps@w3.org; Adrian Bateman
Subject: Re: [FileAPI] Deterministic release of Blob proposal
On Fri, Mar 2, 2012 at 6:54 PM, Feras Moussa fer...@microsoft.com wrote:
To address this issue, we propose that a close method be added to the Blob
interface.
When called, the close method should release the underlying resource of
the
Blob, and future operations on the Blob
On 3/5/2012 3:59 PM, Glenn Maynard wrote:
On Fri, Mar 2, 2012 at 6:54 PM, Feras Moussa fer...@microsoft.com
mailto:fer...@microsoft.com wrote:
To address this issue, we propose that a close method be added to
the Blob
interface.
When called, the close method should release
On Mon, Mar 5, 2012 at 7:04 PM, Charles Pritchard ch...@jumis.com wrote:
Do you see old behavior working something like the following?
var blob = new Blob(my new big blob);
var keepBlob = blob.slice();
destination.postMessage(blob, '*', [blob]); // is try/catch needed here?
blob =
On 3/5/2012 5:56 PM, Glenn Maynard wrote:
On Mon, Mar 5, 2012 at 7:04 PM, Charles Pritchard ch...@jumis.com
mailto:ch...@jumis.com wrote:
Do you see old behavior working something like the following?
var blob = new Blob(my new big blob);
var keepBlob = blob.slice();
On Fri, 02 Mar 2012 23:31:38 +0100, Eric U er...@google.com wrote:
On Thu, Mar 1, 2012 at 11:09 PM, Anne van Kesteren ann...@opera.com
wrote:
Uhm. What you need to do is queue a task that changes the state and
fires the event. You cannot just fire an event from asynchronous
operations.
On Thu, Mar 1, 2012 at 11:09 PM, Anne van Kesteren ann...@opera.com wrote:
On Fri, 02 Mar 2012 01:01:55 +0100, Eric U er...@google.com wrote:
On Thu, Mar 1, 2012 at 3:16 PM, Arun Ranganathan
aranganat...@mozilla.com wrote:
OK, so the change is to ensure that these events are fired directly,
Eric,
On Fri, 02 Mar 2012 01:01:55 +0100, Eric U er...@google.com wrote:
On Thu, Mar 1, 2012 at 3:16 PM, Arun Ranganathan
aranganat...@mozilla.com wrote:
OK, so the change is to ensure that these events are fired
directly,
and not queued, right? I'll make this change. This applies to
At TPAC we discussed the ability to deterministically close blobs with a few
others.
As we've discussed in the createObjectURL thread[1], a Blob may represent
an expensive resource (eg. expensive in terms of memory, battery, or disk
space). At present there is no way for an application to
On 3/2/2012 4:54 PM, Feras Moussa wrote:
At TPAC we discussed the ability to deterministically close blobs with
a few
others.
...
To address this issue, we propose that a close method be added to the
Blob
interface.
When called, the close method should release the underlying
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
On Thu, Mar 1, 2012 at 3:16 PM, Arun Ranganathan
aranganat...@mozilla.com wrote:
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
On Fri, 02 Mar 2012 01:01:55 +0100, Eric U er...@google.com wrote:
On Thu, Mar 1, 2012 at 3:16 PM, Arun Ranganathan
aranganat...@mozilla.com wrote:
OK, so the change is to ensure that these events are fired directly,
and not queued, right? I'll make this change. This applies to all
readAs*
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 part of an implementation.
and be
On Wed, Feb 29, 2012 at 2:36 PM, Arun Ranganathan
aranganat...@mozilla.comwrote:
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?
I don't know, since I think that Unicode to UTF-8 is pretty
in FileAPI? Or can we
merely say to encode as UTF-8 and leave it to implementations (a reasonable
assumption IMHO).
-- A*
I think that gets us by. Do you think we need a reference in FileAPI? Or
can we merely say to encode as UTF-8 and leave it to implementations (a
reasonable assumption IMHO).
I think you should have a reference. You could either use the following, as
does HTML5:
[RFC3629]UTF-8
On Wed, Feb 29, 2012 at 3:43 PM, Glenn Adams gl...@skynav.com wrote:
HTML
A conforming user
agenthttp://dev.w3.org/2006/webapi/FileAPI/#dfn-conforming-implementation
MUST
support at least the subset of the functionality defined in HTML that this
specification relies upon; in particular
] http://dev.w3.org/2006/webapi/FileAPI/
[2] http://lists.w3.org/Archives/Public/public-webapps/2010OctDec/0912.html
with these changes in any way possible.
Thanks,
Feras
-Original Message-
From: Bronislav Klučka [mailto:bronislav.klu...@bauglir.com]
Sent: Friday, February 24, 2012 1:10 PM
To: public-webapps@w3.org
Cc: public-webapps@w3.org
Subject: Re: [FileAPI] createObjectURL isReusable proposal
On Wed, Feb 29, 2012 at 9:38 PM, Feras Moussa fer...@microsoft.com wrote:
Another case: whether loading a one-shot URL from a different origin,
where you aren't allowed to load the content, still causes the URL to
be revoked. (My first impression was that it shouldn't affect it at
all, but
On 1.3.2012 4:38, Feras Moussa wrote:
We think the new property bag (objectURLOptions) semantics in the latest
editors draft are very reasonable. We have an implementation of this and
from our experience have found it very widely used internally with app
developers - many leverage it as a way
On Tue, Feb 28, 2012 at 7:11 AM, Simon Pieters sim...@opera.com wrote:
On Tue, 28 Feb 2012 01:05:44 +0100, Glenn Maynard gl...@zewt.org wrote:
On Mon, Feb 27, 2012 at 5:34 PM, Arun Ranganathan
aranganat...@mozilla.comwrote:
Simon,
Is the relevant part of HTML sufficient to refer to?
On Tue, 28 Feb 2012 13:05:37 +0100, Jonas Sicking jo...@sicking.cc wrote:
If we can't U+FFFD unpaired surrogates on paste, I agree it makes sense
to
U+FFFD them in APIs. If the only way to get them is a JS escape, then an
exception seems OK.
People use JS strings to handle binary data. This
On Tue, Feb 28, 2012 at 1:57 PM, Simon Pieters sim...@opera.com wrote:
My
preference would be to deal with them by encoding them to U+FFFD for
the same reason that we let the HTML parser do error recovery rather
than XML-style draconian error handling.
I'm not really opposed to making APIs
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 jo...@sicking.cc wrote:
I
here.
This is the 29th February Editor's Draft (ensure you shift-reload if
necessary):
http://dev.w3.org/2006/webapi/FileAPI/
I'd appreciate a review. If this passes muster, we may be one step further
along the way to deprecating BlobBuilder, which only stipulated writing out as
UTF-8 when
1 - 100 of 529 matches
Mail list logo