[whatwg] File Upload Progress Event (Upload Progress)
skumar at exposureroom.com
Tue Sep 21 13:09:13 PDT 2010
>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.
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.
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
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:
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
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
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.
More information about the whatwg