[whatwg] File Upload Progress Event (Upload Progress)

[Shiv Kumar]

Aryeh,

>The problem is you're assuming that adding UI requirements to the spec
>will encourage browsers to implement the feature

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

; and/or that
>implementing this feature sooner (at the expense of other possible
>features) is a good idea.  Both assumptions are dubious.

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.

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

Shiv
http://exposureroom.com


-----Original Message-----
From: whatwg-bounces at lists.whatwg.org [mailto:whatwg-bounces at lists.whatwg.org] On Behalf Of Aryeh Gregor
Sent: Tuesday, September 21, 2010 3:33 PM
To: Shiv Kumar; rescator at emsai.net
Cc: WHATWg
Subject: Re: [whatwg] File Upload Progress Event (Upload Progress)

On Mon, Sep 20, 2010 at 2:51 PM, Shiv Kumar <skumar at exposureroom.com> wrote:
> 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.

The difference is in how big the use-case is.  Very common use-cases
are worth considering for declarative markup even if they can be
implemented in script.  But anything but the most common or important
use-cases can be left to script, without special markup.  It's a
matter of prioritizing browser implementers' time -- if it can already
be done somehow and few authors need to do it, it's not worth making
it much easier.  Better to focus effort on allowing totally new
things, and making common things easier.

So the basic issue is that *if* browsers provided good upload UI, your
use-case would be very uncommon.  Thus, instead of asking browser
implementers to add a new and more convenient way to let you add UI,
ask them to spend that same effort adding good UI themselves.  This
will solve your problem and benefit vastly more users (although it
will also probably take more implementer effort in this particular
case).

On Mon, Sep 20, 2010 at 6:38 PM, Roger Hågensen <rescator at emsai.net> wrote:
> Well! There is nothing preventing the specs from providing a minimum UI
> guideline that should be followed by UAs.

All implementers are probably aware of the issue, and apparently don't
think it's worth addressing right now.  How would putting anything in
the spec change that?  It's better to allow browser implementers to
compete and try to figure out themselves what UI changes users
actually want, rather than trying to artificially encourage some
improvements over others by enshrining them in a standard.
Implementers are the ones who should be deciding how they spend their
time -- specs should mainly ensure that the new features they do
decide to add can be easily made compatible with other browsers' new
features.

This is not comparable to requirements on authors, because there are
an extremely large number of authors and most of them know very little
about web technology.  Validators are useful mostly because they tell
authors about problems that they wouldn't have known about otherwise.
Implementers are much fewer, better funded, better organized, and
better informed, so specs aren't a useful tool to tell them new
things.  Indeed, implementers typically write the specs, or at least
have a major hand in shaping them.

The problem is you're assuming that adding UI requirements to the spec
will encourage browsers to implement the feature; and/or that
implementing this feature sooner (at the expense of other possible
features) is a good idea.  Both assumptions are dubious.