[whatwg] File Upload Progress Event (Upload Progress)

[Aryeh Gregor]

On Tue, Sep 21, 2010 at 4:09 PM, Shiv Kumar <skumar at exposureroom.com> wrote:
> Yes, I guess in way. Including it in a spec gives them guidelines so the chances of all implementers providing the same info goes up. I think that is the point of the spec (providing guidelines).

No, the main point of a spec is allowing interoperability.  E.g., to
make sure that you don't have a situation where Mozilla makes up
something called localStorage, and then Microsoft makes up something
called persistentStorage that does basically the same thing, and then
authors have to tediously write code like "if localStorage exists use
that, otherwise use persistentStorage", and then newcomers to the
browser market have to pretend to be an existing browser and
reverse-engineer all its features.  That's the web of the 1990s, and
that's what web standards are meant to avoid.  Instead, browsers that
want to add a new feature write a spec and make sure other browsers
are interested and have reviewed it, so that when the other browsers
implement it, their implementation is interoperable.  Everything else
is secondary at best.

> I don't believe I've said anything that would imply anything I have proposed be given priority over anything else that's already in the pipeline. I'm beginning to wonder why you say that. You're the second person making this assumption/comment.

Because otherwise, why would you want it in the spec?  Implementers
have already been informed it's a problem -- the Mozilla bug on the
subject is years old.  The only problem is they haven't allocated the
resources to fixing it properly, because they think other things are
more important.  So the only way to encourage them to fix it (other
than code it yourself, for the open-source ones) would be to try
changing their priorities, such as by adding a requirement in some
spec and then trying to pressure them with "you're not obeying the
standard!" in addition to pragmatic arguments.

> It's fine/great if implementers provide a UI for this. I didn't ask for this by the way. What I did ask for was an upload progress event.
>
> Typically, in an enterprise environment or public website, standard UI is key to providing the end user with a good experience. That is a standard UI across all browsers. This also goes a very long way in being able to provide good customer support. So it becomes important to provide one's own UI for this sort of thing and hence the event.

Do you write your own UI for *download* progress?  If not, why not?

> Of course I've noted earlier that events are more approachable than having to script every existing and future form submission, especially considering that more and more videos will be shuttled across the internet in the coming years. That, and in keeping with Html (rather than JavaScript) I believe a form should have an onUploadProgress event (just like it has onsubmit).
>
> Personally (and frankly), I've been doing it for so many years now it makes no difference to me. I'm looking at a much bigger picture, which is why I joined this group.

We're all looking at the bigger picture here.  But I think this
discussion is going in circles now.