Join MDN and developers like you at Mozilla's View Source conference, 12-14 September in Berlin, Germany. Learn more at


What is the maximum number that can be used with the max property? I think this must be documented.

PhoneixS 2011/03/18 19:35


Moving this text here to be worked on. It's way too much text for what it's trying to say, and the example needs to be real code.

 - Enn

Note that the state of the art in progressmeter accuracy, across applications that the user sees, is rather crude. They often jump forward unexpectedly or pause for long periods of time in one spot. They may start or end half way across. This is alarming for the common consumer user. The experienced user, however, is used to this. So if your audience uses a command line, don't spend a lot of time on a crafty algorithm to do a difficult prediction, unless it really is a process that makes the user wait for minutes or hours.

All users look at a progress meter to make sure that the program hasn't hung up or halted at some error situation. So these functions are paramount. The important things to remember are:

  • Show movement every few seconds, or every 1%, whichever is larger.
  • Don't run the progress meter from a separate thread, unless that thread actually measures overall progress and sets the bar based on that measurement. Otherwise, your progressmeter is measuring the progress of the thread, not the original process, and you are decieving the user. The process could be hung or crashed and your progressmeter will be happily chugging along, misrepresenting ongoing success.
  • Don't run several progressmeters, or several runs of one progressmeter, each showing progress over one piece of the overall. That information is useless and misleading, as the meter could be showing 10% when the process is 90% complete, or vice versa. Remember that your users have not memorized which subprocess comes before what and how slow each subprocess is. You need to integrate that into the information that the user can use: total progress.

Have one run of the meter that shows the overall progress, start to finish. Allocate, say, 20% of the width to the first subprocess, 40% to the second subprocess, and so on. Or if different subprocesses depend on variables like the number of foos, have a point system and at the end divide by the points.

Example: Your benchmarks (on one machine) show that it takes:

  • 1 sec of overhead before the first foo
  • .5 sec of overhead for each foo
  • 2 secs of overhead between the foos and the bars
  • .1 sec of overhead for each bar
  • 4 secs to clean up at the end and get rid of the dialog
(pseudocode only approximate - adapt to your purposes)

function doprogress

var totalPoints = 1 + 0.5*nFoos + 2 + 0.1*nBars + 4;
var fooStart = 100 *(1) / totalPoints;
var fooEnd = 100 *(1 + .5*nFoos) / totalPoints;
var barStart = 100 *(1 + .5*nFoos + 2) / totalPoints;
var barEnd = 100 *(1 + .5*nFoos + 2 + .1*nBars) / totalPoints;

progress.value = 0;
for (foo = 0; foo < nFoos; foo++)
   progress.value = fooStart + 0.5*foo;

progress.value = fooEnd;
for (bar = 0; bar < nBars; bar++)
   progress.value = barStart + 0.1*bar;
progress.value = barEnd;
progress.value = 100;

Document Tags and Contributors

 Contributors to this page: PhoneixS, Enn
 Last updated by: PhoneixS,