- From: Charles McCathieNevile <chaals@opera.com>
- Date: Wed, 07 Mar 2007 17:38:32 +1100
- To: "Ian Hickson" <ian@hixie.ch>, "Bjoern Hoehrmann" <derhoermi@gmx.net>
- Cc: "web API" <public-webapi@w3.org>
To+: Bjoern. Bjoern, could you please review this specification for compatibility with DOM3 events? On Wed, 07 Mar 2007 13:19:46 +1100, Ian Hickson <ian@hixie.ch> wrote: > On Wed, 7 Mar 2007, Charles McCathieNevile wrote: >> >> http://dev.w3.org/cvsweb/~checkout~/2006/webapi/progress/Progress.html > > Early comments: Thanks for these. There is a new draft, incorporating some changes as discussed further below... > XmlHttpRequest should be XMLHttpRequest. Yup. > I disagree with "in general specifications should not specify that > progress events must occur". Me too, and removed it. > 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. Hmm. This draft marks a change in underlying assumptions. Having thought about it, I removed that section as it doesn't seem applicable to the new approach. > 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'. All these are fine by me. > 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 doesn't mention 'error' or 'abort', but the ways to arrive at various end states are indeed not clearly distinguished. @@ToDo > The spec says that the events must be cancelable but does not define their > default action. Right. Do you have a suggestion for a default action? Is there a reason we need one for everybody to implement? > The initialisation methods for ProgressEvent are missing a > lengthComputableArg argument in the IDL. Whoops. Fixed. > 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." Could you explain what you mean by "makes no sense"? Tightening up the use of RFC 2119 terminology is one thing, but the idea seems simple to me. > The specification is lacking requirements on user agents to set the event > attributes appropriately. Yep. > 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. That section could be significantly improved to make it easier and help it happen in an interoperable way. @@ToDo > Please have Bjoern review this specification for consistency with DOM3 > Events. I have as much control over Bjoern as you do, but this is explicitly cc'ed to him as a request that he takes a look. > 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). Yep. Fixed. Cheers Chaals -- Charles McCathieNevile, Opera Software: Standards Group hablo español - je parle français - jeg lærer norsk chaals@opera.com Try Opera 9.1 http://opera.com
Received on Wednesday, 7 March 2007 06:38:57 UTC