[whatwg] File Upload Progress Event (Upload Progress)
skumar at exposureroom.com
Mon Sep 20 11:51:47 PDT 2010
Ok let me put this another way...
In order to show a upload progress using the new FileAPI/FormData I'd have to write the event handler so I can control the way I want things displayed. I'd have to write the same event handler code to show upload progress if I were to hook into my proposed onuploadprogress event too.
So far so good?
The difference is that I didn't have to mess with the FileAPI/FormData stuff to do it. Frankly, if we have one (FileAPI/FormData that has a progress event) I don't see why we can't have the other. The difference is I'm subscribing to the event declaratively (more Html like). Browser vendors would already have the ability to do this once they implement the FileAPI.
>(for a more limited subset of use-cases),
>but there's no reason to think it will be specced and implemented
>before all the stuff that's already being worked on.
From: whatwg-bounces at lists.whatwg.org [mailto:whatwg-bounces at lists.whatwg.org] On Behalf Of Aryeh Gregor
Sent: Monday, September 20, 2010 2:12 PM
To: Shiv Kumar
Subject: Re: [whatwg] File Upload Progress Event (Upload Progress)
On Sun, Sep 19, 2010 at 11:42 PM, Shiv Kumar <skumar at exposureroom.com> wrote:
> At the same time, if I were to use Flash to upload the file, I don't need server side support to show progress and almost every website (that deals with large file uploads) today uses Flash to display upload progress to their users.
This is only because the File API and related things aren't widely
going to be easier than writing it in Flash, when all browsers support
the necessary already-specced JS features. Your feature would also
work to replace Flash here (for a more limited subset of use-cases),
but there's no reason to think it will be specced and implemented
before all the stuff that's already being worked on.
> I agree! I'd love to see browsers provide their own information in a more noticeable/useful fashion, but I still think surfacing the event and information allows web developers the option to display such information in a consistent manner (across browsers) without having to resort to handling the entire submission process using XMLHttpRequest.
I don't think this would be necessary at all if browsers provided good
UI, comparable to what they provide for downloads. Very few authors
would feel the need to override good native UI -- how many try to
override the native download UI? -- so requiring them to use XHR would
be fine. Unfortunately, there's not much for us to do to get
implementers to improve UI for large uploads, but I don't think
speccing features to allow authors to more easily work around bad
browser UI is a good strategy.
More information about the whatwg