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
