Re: Not making partial result available during FileReader.readAsText()?

This sounds good. I have one more question related to this.

What are we going to set for total and loaded attributes for ProgressEvent?
Is it based on the decoded text or the underlying binary data?


On Fri, Apr 9, 2010 at 6:59 PM, Jonas Sicking <jonas@sicking.cc> wrote:

> I think the spec should say MUST here, rather than SHOULD. Streaming
> contents seems as useful for text files as for binary files.
>
> The one thing that was tricky for us when implementing this was
> charset detection. We can't really expose any data until we've decided
> what charset to decode it with. However when loading normal pages over
> http the same situation arises, and all major browsers support
> streaming there.
>
> So I consider it a bug that firefox doesn't support this yet. It's
> something we should fix.
>
> / Jonas
>
> On Fri, Apr 9, 2010 at 6:33 PM, Jian Li <jianli@chromium.org> wrote:
> > Should we really want to support this? As I know, FF 3.6 does not support
> > this in its current FileReader implementation. I just want to understand
> if
> > there is a strong need for this.
> >
> > On Fri, Apr 9, 2010 at 5:49 PM, Michael Nordman <michaeln@google.com>
> wrote:
> >>
> >> Seems pretty clear from the snippet you provided, it says you SHOULD
> >> provide partially decoded results in the result attribute as progress is
> >> made.
> >>
> >> On Thu, Apr 8, 2010 at 8:31 PM, Jian Li <jianli@chromium.org> wrote:
> >>>
> >>> For FileReader.readAsText, the spec seems to allow partial file data
> >>> being decoded and saved in the result attribute when progress event is
> >>> fired:
> >>>
> >>> Make progress notifications. As the bytes from the fileBlob argument
> are
> >>> read, user agents SHOULD ensure that on getting, the result attribute
> >>> returns partial file data representing the number of bytes currently
> loaded
> >>> (as a fraction of the total) [ProgressEvents], decoded in memory
> according
> >>> to the encoding determination.
> >>>
> >>> The partial file data read so far might not get decoded completely.
> Could
> >>> we choose not to decode the partial result till we retrieve all the
> data,
> >>> just like what FileReader.readAsDataURL does?
> >>
> >
> >
>