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

Re: New Progress Events spec

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>
Message-ID: <op.tos3eip0wxe0ny@widsith.local>

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.


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


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



 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

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