On Mon, Aug 17, 2009 at 2:45 AM, Olli Pettay wrote:
> On 8/17/09 12:33 AM, Michael Nordman wrote:
>>
>> Strictly speaking, I think the seperate 'Reader' class makes for a more
>> correct API. The two corners above would not conflict since each would
>> presumably be working with a distinct FileRead
On Mon, Aug 17, 2009 at 11:13 PM, Nikunj R.
Mehta wrote:
>
> On Aug 17, 2009, at 11:08 PM, Jonas Sicking wrote:
>
>> On Mon, Aug 17, 2009 at 6:01 PM, Arun Ranganathan wrote:
>>>
>>> Nikunj R. Mehta wrote:
On Aug 5, 2009, at 6:55 PM, Jonas Sicking wrote:
> What's the use-case for
On Aug 17, 2009, at 11:08 PM, Jonas Sicking wrote:
On Mon, Aug 17, 2009 at 6:01 PM, Arun Ranganathan
wrote:
Nikunj R. Mehta wrote:
On Aug 5, 2009, at 6:55 PM, Jonas Sicking wrote:
What's the use-case for getAsBase64?
I have another use case for this. The Atom Publishing protocol per
On Mon, Aug 17, 2009 at 6:01 PM, Arun Ranganathan wrote:
> Nikunj R. Mehta wrote:
>>
>> On Aug 5, 2009, at 6:55 PM, Jonas Sicking wrote:
>>
>>> What's the use-case for getAsBase64?
>>
>>
>> I have another use case for this. The Atom Publishing protocol per RFC
>> 5023 [1] accepts inline binary data
On Mon, Aug 17, 2009 at 2:45 AM, Olli Pettay wrote:
> I'd do
> var reader = new DataReader(someDataObject, DataReader.BINARY);
> reader.onload =
> function(evt) {
> // grab the data using evt.target.getData();
> };
> reader.read();
What's the advantage of this API over what I proposed? Seems
I think it'd be great to have a *simple to use* API specifically for
loading local files on local pages (file://).
There's already DOM3 Load and Save, but few want anything to do with that
(it's not simple for one).
There's also the previous document.load, but it's half broken in Opera,
n
Nikunj R. Mehta wrote:
On Aug 5, 2009, at 6:55 PM, Jonas Sicking wrote:
What's the use-case for getAsBase64?
I have another use case for this. The Atom Publishing protocol per RFC
5023 [1] accepts inline binary data represented in base 64 encoding.
In order to submit binary inline content
On Mon, 17 Aug 2009 20:12:50 -0400, Arun Ranganathan
wrote:
Nikunj R. Mehta wrote:
On Aug 12, 2009, at 7:29 AM, Arun Ranganathan wrote:
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?
Nikunj R. Mehta wrote:
On Aug 12, 2009, at 7:29 AM, Arun Ranganathan wrote:
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 Fil
On Aug 5, 2009, at 6:55 PM, Jonas Sicking wrote:
What's the use-case for getAsBase64?
I have another use case for this. The Atom Publishing protocol per RFC
5023 [1] accepts inline binary data represented in base 64 encoding.
In order to submit binary inline content in an Atom entry to a
On Aug 12, 2009, at 7:29 AM, Arun Ranganathan wrote:
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 U
On Aug 12, 2009, at 4:40 AM, 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 scheme
The Application Cache feature in HTML5 uses an event named 'progress' as
part of the process, in a manner mostly unrelated to the rest of the
progress events feature. It needs two values of context information
(number of files being downloaded, number of files obtained so far).
Should I just r
Is there a record anywhere of outstanding feedback on the progress events
spec? I looked in the issue tracker but there was only one issue there.
I was trying to integrate HTML5 with Progress Events today and found the
following problems:
- ProgressEvent.total has a requirement that I don't f
I've now written the first draft of the P&C test suite Prologue which
tells people how to write a test and what templates they can use. I've
also outlined what user agents need to support to run the tests (at a
mim, HTML4.01, and CSS 1 - though the tests are written to conform to
HTML5). I'm still
Michael Nordman wrote:
Currently we have File and FileData, where a File object ISA FileData
object... completion is delivered via readXXX method completion callbacks.
It would be easy to add progress callbacks to those readXXX methods.
I think Garrets point about two different corners of the web
On Fri, Aug 14, 2009 at 6:46 PM, Jeff
Decker wrote:
> Hi All,
>
> I noticed in the P&C under Section 8.8.1 "Attributes of the author Element"
> that the href attribute includes a line saying "It is optional for authors
> to use the xml:lang attribute with an author element."
>
> Is this meant to in
On 8/17/09 12:33 AM, Michael Nordman wrote:
Strictly speaking, I think the seperate 'Reader' class makes for a more
correct API. The two corners above would not conflict since each would
presumably be working with a distinct FileReader object. And the
seperate 'Reader' with event handlers seems m
Hi,
We have been going through the latest Early Draft [1] of the Window
Modes spec and I have followed the latest discussion that I could
discern from the mailing list ([2], [3]).
There was a request for feedback on the window modes spec and I hope
this feedback is useful and timely.
Initially
19 matches
Mail list logo
