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

Re: New draft of Progress events

From: Charles McCathieNevile <chaals@opera.com>
Date: Sun, 28 Jan 2007 12:51:49 -0500
To: "Anne van Kesteren" <annevk@opera.com>, "Web API WG (public)" <public-webapi@w3.org>
Message-ID: <op.tmvk8nf9wxe0ny@widsith.local>

On Sun, 28 Jan 2007 10:41:31 -0500, Anne van Kesteren <annevk@opera.com>  
wrote:

> * The specification should make it clear that other specifications must 
> define when it is to be dispatched. (This should be also be made clear 
> for the examples.)

Sure, but my current approach to ISSUE-106 is that it never has to fire.  
Other
specs therefore *may* define when they think it should fire. Otherwise user
agents can just fire it as they please during asynchronous network  
operations.

IMHO authors should never rely on it firing, primarily because if they do  
then
they break backpat for no particularly good reason that I can see. So  
specs *should
not* say it *must* fire...

> * "The user agent may dispatch a progress event while an asynchronous 
> network opertation such as a load event is taking place." doesn't make 
> much sense to me.

apart from the typo, and changing "load event" (which I meant there in the
everyday sense of 'occurrence' but which is probably really confusing) to  
"load
operation", is there anything you can suggest to make it clearer?

> * "These events should not bubble, and can be canceled." -> "Theseevents 
> must not bubble and most be cancelable."

must be cancelable - agreed. Not sure that we should be upset if some user  
agent
does allow them to bubble, although since they should not authors relying  
on it
are a bit mad. Anyone else want to throw their weight behind must not  
bubble?

> * I think initProgressEvent and initProgressEventNS should just defer to 
> initEvent and initEventNS for details on multiple invocations (in case 
> that changes at some point).

I think once we put the spec out, making this particular part depend on
something that might change later doesn't help interoperability, so I would
prefer we define what happens here and stick with it. But I am not  
particularly
wedded to that. I've raised ISSUE-111.

> * What seems to be missing is a normative reference to DOM Level 3Events.
>
> * The [IEoP] is never referenced. Either reference it or drop the 
> reference.

Indeed. The reference section is on the To Do list...

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 Sunday, 28 January 2007 17:51:46 GMT

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