[whatwg] File Upload Progress Event (Upload Progress)
skumar at exposureroom.com
Mon Sep 20 02:10:21 PDT 2010
>Well, events aren't "declarative", and you explicitly
>asked for progress events ;)
Ok, without getting into semantics...
If I have:
<input type="file" id="somefilefield" onuploadprogress="displayProgress()"/>
The onuploadprogress event could either be on the <form> or on the <input>. Having it on the input gives you the ability to show progress for multiple files, however, browsers may choose the upload one file at a time.
I'm not saying the scripting method is not useful or should not be there. The html way should be an option. And yes, I know the XmlHttpRequest along with FormData does not require any server side support (besides standard multipart/form-data support). I mentioned that that's how one has to do it today due to the lack of this feature.
From: Olli Pettay [mailto:Olli.Pettay at helsinki.fi]
Sent: Monday, September 20, 2010 4:16 AM
To: Shiv Kumar
Subject: Re: [whatwg] File Upload Progress Event (Upload Progress)
On 09/20/2010 06:42 AM, Shiv Kumar wrote:
> Areyah, thanks for your inputs thus far.
>> At that point, the user is already in the process of navigating
>> away from the page.
> Keep in mind that I'm talking about large file uploads. For the
> typically user that takes about 2-6 hours. So they may be in the
> process of navigating away, but that process takes a very long time.
> I do understand that I can script my way to doing pretty much
> anything I please.
> I guess I should have been clearer in my previous post.
> What I hope is that the new specs are more about enabling Html and
> allowing someone to do something in a declarative manner (to the
> extent possible) rather than resort to scripting each time they want
> to do something.
Well, events aren't "declarative", and you explicitly
asked for progress events ;)
And so my suggestion...
> Use case I'm uploading a large file using an iframe. So yes, the
> iframe will be submitted, but the rest of the page is intact. I'm
> still left without having the ability to know how long the upload is
> going to take and how it is progressing. So while the form is
> submitting, today we go through quite a bit of hackry to show our
> users progress.
Uploading the form data or files using XMLHttpRequest isn't
> Having the event
Again, event isn't "declarative". It is all about scripting, in which
case you could just use XMLHttpRequest.
and information allows us to provide
> a consistent (across browsers) interface which is extremely important
> (as you can imagine) and does not require the server side to support
The XHR way doesn't need any special server side handling.
> Currently, we monitor the bytes received on the server side
> (and no web server gives you easy access to this information) and
> make that available (per session) to the client UA.
> 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.
>> I do think browser UI for large uploads is terrible and needs to
>> be fixed.
> I agree!
Yeah, the UI is terrible, but that is about browser implementations and
not about any specification.
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. Chrome in fact does show a percentage in the status
> bar but how many people have noticed? And with todays browser
> trending towards less "chrome" it would mean unless the user has
> turned on the status bar this info will not be visible.
> Shiv http://exposureroom.com
More information about the whatwg