- From: Maciej Stachowiak <mjs@apple.com>
- Date: Sat, 10 Feb 2007 16:03:59 -0800
- To: Charles McCathieNevile <chaals@opera.com>
- Cc: Ian Hickson <ian@hixie.ch>, Web APIs WG <public-webapi@w3.org>
On Feb 10, 2007, at 1:47 AM, Charles McCathieNevile wrote: > >>> 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. >> >> Maciej's model seems amenable to this too. I don't think Maciej is >> arguing >> that the existing events (namely, 'load', 'error', and 'abort') >> should be >> dropped, or made redundant; I would expect his proposed processing >> model >> to augment them. > > My understanding is that they are made redundant by being > replicated by events > that are required to fire by the progress event spec, although I > may have missed > something there... On the contrary, I proposed making these part of the progress events spec, and cited them as not redundant with any progress events if you want to give proper UI feedback. The only place where my proposal might diverge from existing mechanisms is the "loadstart" event, since there is no general way to detect this point in time. Regards, Maciej
Received on Sunday, 11 February 2007 00:04:26 UTC