Re: Progress event spec

On Sat, 27 Jan 2007, Ian Hickson wrote:
> 
> I haven't actually looked at the spec, but, I would recommend something 
> along the lines of:

Apparently I should have given rationales, so:

>    MUST fire at zero bytes

...so that progress bars can be initialized with the right length, or 
indeterminate length if there is no right length.

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

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

>    SHOULD NOT fire more than once every 10ms.

...so that poorly written code doesn't result in fatal performance hits.


It's important, in terms of API design, to make the main use cases 
trivial. I believe the above design would do that.

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

(Further to that, if the 'progress' event does indeed go ahead with 
setting 'max' to 0 when it is unknown, I'll update the HTML5 spec to make 
max=0 cause an indeterminate progress bar, thus making it even simpler.)

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Saturday, 27 January 2007 20:45:11 UTC