- From: Maciej Stachowiak <mjs@apple.com>
- Date: Tue, 6 Mar 2007 19:13:58 -0800
- To: Charles McCathieNevile <chaals@opera.com>
- Cc: web API <public-webapi@w3.org>, WAI PF public <wai-xtech@w3.org>
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 compatibility. - 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 "computable". Regards, Maciej
Received on Wednesday, 7 March 2007 04:55:00 UTC