- From: Shiv Kumar <skumar@exposureroom.com>
- Date: Mon, 20 Sep 2010 14:51:47 -0400
Aryeh, 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. >From your arguments (it can be done using script) we don't need all of the new form elements then do we? We can simply implement their functionality using JavaScript like, we've been doing for a decade or so. I feel what I'm asking for is in line with the same thinking that went behind the new form elements. >(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 don't expect anything frankly, I only hope :). But I'm not hoping for priority of implementations, but rather that it be added to the spec. Uploading large files is going to be more "common" than it is today, and this feature should be made more accessible/approachable I feel. Just because you and I can do all this in script doesn't mean everyone else has to. And yes, I do distinguish between writing event handlers and other JavaScript. People find it a lot easier to write an event handler (showing progress) than having to new up objects, know their methods and properties and deal with protocols and such. An event handler isolates them from having to know how all this works and concentrate on what they're trying to do and that is show a progress bar. Shiv http://exposureroom.com -----Original Message----- From: whatwg-bounces@lists.whatwg.org [mailto:whatwg-bounces@lists.whatwg.org] On Behalf Of Aryeh Gregor Sent: Monday, September 20, 2010 2:12 PM To: Shiv Kumar Cc: WHATWg 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 supported yet. Writing the upload progress in JavaScript is certainly 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.
Received on Monday, 20 September 2010 11:51:47 UTC