Re: Progress event spec

"Ian Hickson" <ian@hixie.ch>
>>    MUST fire again at the end, even if that is zero bytes
>
> ...so that progress bars can be easily guarenteed to reach the 100% mark,
> which is important for usability.

Using onload is sensible for that, there is no point to require an extra 
event which breaks backwards compatibility.

>>    SHOULD fire at least once every 500ms in between the above two events,
>>    unless no progress has been made in that time.
>
> ...so that smooth UI can be guarenteed.

How does firing every 500ms guarantee that?  (or even achieve it?)  This 
should be very much down to the user agent, there is no need to specify 
this.

>>    SHOULD NOT fire more than once every 10ms.
>
> ...so that poorly written code doesn't result in fatal performance hits.

So why is the value 10ms chosen?  poorly written code could as easily be 
written to take up 15ms to execute as 9ms.  I see no reason to specify a 
value for this, the user agent is in a strong position to know what's 
appropriate.

> In the common case, I would expect a 'progress' event to simply update the
> "max" and "value" attributes of the HTML5 <progress> element; with the
> above characteristics, such an event handler becomes a trivial two-line
> handler with no complications, and you would not need any other handlers
> to do anything special (e.g. no need to track the 'load' event to end
> the progress bar).

You certainly would, because there is no guarantee that the Max value won't 
change between updates (servers might advertise a content-length different 
to what it actually is for example) to put a progress bar into a loaded 
state the onload should be used, it's reliable, it's backwards compatible in 
a lot of places where progress events will be used and the complication for 
an author is 1 short line.

Cheers,

Jim.

Received on Saturday, 27 January 2007 21:11:52 UTC