- From: Charles McCathieNevile <chaals@opera.com>
- Date: Sat, 10 Feb 2007 14:27:06 +0530
- To: "Ian Hickson" <ian@hixie.ch>, "Web APIs WG" <public-webapi@w3.org>
On Sat, 10 Feb 2007 13:01:12 +0530, Ian Hickson <ian@hixie.ch> wrote: > > On Sat, 10 Feb 2007, Web APIs Issue Tracker wrote: >> >> Is it worth adding to progress events to support this use case, or >> should it stay as small as possible? > > Are there any other actual use cases? What else would you use the progress > events for if not a standard progress UI? Measuring how your network operations are going, whether to time them out andswap to something else, ... The issue here though is actually whether you should be able to build yourentire UI on nothing but progress events, or whether you should rely on otherspecifications for things like the start and end, and get them to define thatprogress events can be fired. In that scenario, if you build a UI element you would make a standard UI widget that assumed no progress events, and a progress event extension that, if it got them, would refine the UI widget by adding some sense of progress. For example,a rectangular bar might normally have a cylon eye effect, but if you get progress events that tell you how far along you are you could change that to have a proportional progress bar. As Maciej points out, that means you have to write widgets for each type of operation that might fire progress events. On the other hand it means you aren't relying on progress events in order to have at least some UI. And it lightens the requirements on the progress event spec. cheers Chaals -- Charles McCathieNevile, Opera Software: Standards Group hablo español - je parle français - jeg lærer norsk chaals@opera.com Try Opera 9.1 http://opera.com
Received on Saturday, 10 February 2007 08:57:30 UTC