- From: Ian Hickson <ian@hixie.ch>
- Date: Wed, 7 Mar 2007 02:19:46 +0000 (UTC)
- To: Charles McCathieNevile <chaals@opera.com>
- Cc: web API <public-webapi@w3.org>
On Wed, 7 Mar 2007, Charles McCathieNevile wrote: > > http://dev.w3.org/cvsweb/~checkout~/2006/webapi/progress/Progress.html Early comments: XmlHttpRequest should be XMLHttpRequest. I disagree with "in general specifications should not specify that progress events must occur". I don't think requiring these events causes any backwards incompatibilities. The incompatibility is if someone in new content assumes those events take place, but that will happen whether or not a requirement uses a SHOULD requirement. In fact the entire "Considerations for Backward Compatibility" section doesn't really make any sense to me. I think the event 'progressStart' should be called 'start'. I think the event 'progressError' should be 'error' for backwards compatibility. I think the event 'progressCanceled' should be 'abort' for backwards compatibility. I think the event 'progressComplete' should be 'load' for backwards compatibility'. The spec doesn't say how to decide whether to fire 'error' or 'abort'. The spec implies that 'error' and 'abort' are not mutually exclusive with 'load'. The spec says that the events must be cancelable but does not define their default action. The initialisation methods for ProgressEvent are missing a lengthComputableArg argument in the IDL. The following requirement both abuses RFC2119 terminology and makes no sense from a conformance point of view: "This method may only be called before the progress event has been dispatched via the dispatchEvent method, though it may be called multiple times during that phase if necessary." The specification is lacking requirements on user agents to set the event attributes appropriately. I would recommend changing the start of the "The ProgressEvent events" section to more clearly indicate exactly what it is other specifications are to do. As it stands I don't know that I'd be able to appropriately use this specification to write another one that uses these events in a fully well-defined and unambiguous way. Please have Bjoern review this specification for consistency with DOM3 Events. The acknowledgements refer to the "WHATWG progress event proposal" as being "invaluable in preparing this draft", but that seems unlikely since there is no such proposal (the provided reference is to the <progress> element, a UI widget). HTH, -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Wednesday, 7 March 2007 02:20:03 UTC