Re: New Progress Events spec

On Wed, 7 Mar 2007, Charles McCathieNevile wrote:
> >
> > 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.

Sorry, s/error/progressError/, s/abort/progressCanceled/, and 
s/load/progressComplete/ in the above comments; I was assuming the earlier 
changes were accepted by the time I got to that comment. :-)


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

If there isn't one, it should just say so.


> > 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"?

"may only" is not RFC2119-compatible grammar.

It also doesn't really make much sense to give conformance requirments on 
when a method call can be called. It's not formally checkable, and we have 
to define what happens when the requirement is violated anyway.

Cheers,
-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Wednesday, 7 March 2007 19:17:31 UTC