Re: New Progress Events spec

On Mar 6, 2007, at 10:39 PM, Charles McCathieNevile wrote:

> On Wed, 07 Mar 2007 14:13:58 +1100, Maciej Stachowiak  
> <> wrote:
>> - "User agents may dispatch one or more ProgressEvent of type
>> progress while a network operation is taking place." -- per my
>> earlier use cases document, I'd like to suggest requiring dispatching
>> at least one as the size is known (or definitely known to be  
>> unknown).
> Can you definitively know that the size is unknown?

With http, yes, you can tell that you won't know it until you get all  
the data. Probably similar for other protocols.

> If the size is known to be zero, why have to fire the extra event?

Actually, I think it's fine not to fire it for size 0 (or in general  
if it's ready to fire when the load is already complete, but that  
might water down the conformance requirement to meaninglessness).

> When the size is known, that knowledge is not necessarily accurate.

Can you cite an example?

> For these reasons, but also because I am still a minimalist, I am  
> not sure we should do this - so haven't yet made the change. What  
> do others think?
>> - "These events must not bubble, and must be cancelable." -- I
>> suggest making these not cancelable, since there's no default action
>> to prevent.
> When discussed at the face to face - 
> Public/public-webapi/2007Feb/att-0023/f2f5.html#item06 - the reason  
> to make it cancelable was that while there is no defined default  
> action, there might be a user agent default widget, and an  
> application author may wish to cancel that and provide their own  
> widget. Is there a better way to enable this than making the event  
> cancelable?

I don't know of any user agent that has per-resource progress UI that  
it would make sense to cancel. Most browsers have a single progress  
bar that covers loading of all resources during initial page load, I  
don't think there's any sensible way to interpret cancelling progress  
events for only a single resource for purposes of the overall  
progress bar. In Safari, we also show size loaded so far per resource  
and whether it is complete in a separate Activity window, I also do  
not think it makes sense to cancel this.

Can whoever suggested this be more specific about what they had in mind?

>> - "readonly boolean lengthComputable" -- I suggest renaming this to
>> "totalKnown", to avoid arbitrary inconsistency with the name of the
>> "total" attribute, and because "known" is more accurate than
>> "computable".
> it began that way for compatibility with existing implementations,  
> so I am waiting to hear what others say.

What implementations have "lengthComputable" and "total"? Are these  
SVG 1.2 implementations? Since all the event names are changing, I'm  
not sure this is relevant. But the name is not the world's most  
important thing.


Received on Wednesday, 7 March 2007 07:39:36 UTC