[whatwg] File Upload Progress Event (Upload Progress)

[Shiv Kumar]

>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()"/>

for example is a lot more approachable (and easy to modify existing code) than having to submit the form using the FileAPI or FormData along with XMLHttpRequest. And yes you can create a Javascript library method that submits the form for you by passing it the id of the form element, but you'll still need to implement that event handler to be able to customize it the way you need. So rather than go full circle, let's just have any event :)


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.

Shiv
http://exposureroom.com


-----Original Message-----
From: Olli Pettay [mailto:Olli.Pettay at helsinki.fi] 
Sent: Monday, September 20, 2010 4:16 AM
To: Shiv Kumar
Cc: 'WHATWg'
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
a hack.


> 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
> this.
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.


-Olli


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
>
>