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

Re: New Progress Events spec

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>
Message-ID: <Pine.LNX.4.62.0703070208020.30348@dhalsim.dreamhost.com>

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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:18:57 GMT