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

Re: New Progress Events spec

From: Maciej Stachowiak <mjs@apple.com>
Date: Tue, 6 Mar 2007 19:13:58 -0800
Message-Id: <53948616-E0A6-4EDE-9B54-43E906A465AC@apple.com>
Cc: web API <public-webapi@w3.org>, WAI PF public <wai-xtech@w3.org>
To: Charles McCathieNevile <chaals@opera.com>

On Mar 6, 2007, at 6:02 PM, Charles McCathieNevile wrote:

> http://dev.w3.org/cvsweb/~checkout~/2006/webapi/progress/ 
> Progress.html?rev=1.8
> I would appreciate review, and in particular propose to publish  
> this spec as a First Public Working Draft more or less in its  
> current shape.

I think it's fine for FPWD, other comments notwithstanding.

> All other comments and criticisms are of course appreciated...

I'll mostly try not to duplicate Ian's comments, though I agree with  
many, but two stand out as worth repeating:

- The terminal events should be load/abort/error rather than  
progressComplete/progressCancel/progressError, for better backwards  

- The spec should not recommend that other specs make dispatch of  
progress events optional. Specifications add new features over time,  
and it doesn't make sense to require all new features to be optional.  
Nothing about progress events makes them a special case for this.

Other comments:

- Conformance section -- the spec should define conformance classes.  
I suggest "conforming implementation" and a conformance class for  
specs that define use of progress events, much like the conformance  
classes for the access-control spec.

- "A progress event occurs when the user agent makes progress in some  
network operation" -- perhaps this should be "data transfer  
operation", as it might not necessarily be over a network.

- "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).

- "These events must not bubble, and must be cancelable." -- I  
suggest making these not cancelable, since there's no default action  
to prevent.

- "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  

Received on Wednesday, 7 March 2007 04:54:58 UTC

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