W3C home > Mailing lists > Public > public-webapi@w3.org > February 2007

Re: ISSUE-112: Should progress run a UI or rely on other stuff too?

From: Maciej Stachowiak <mjs@apple.com>
Date: Sat, 10 Feb 2007 16:03:59 -0800
Message-Id: <EE3575EA-92C1-42C8-971C-DDD0E36FCB5F@apple.com>
Cc: Ian Hickson <ian@hixie.ch>, Web APIs WG <public-webapi@w3.org>
To: Charles McCathieNevile <chaals@opera.com>

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.

Received on Sunday, 11 February 2007 00:04:26 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:16:23 UTC