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

Re: New draft of Progress events

From: Anne van Kesteren <annevk@opera.com>
Date: Sun, 28 Jan 2007 19:00:09 +0100
To: "Charles McCathieNevile" <chaals@opera.com>, "Web API WG (public)" <public-webapi@w3.org>
Message-ID: <op.tmvlmjdk64w2qv@id-c0020.nomadprime.subscribe.loganwifi.com>

On Sun, 28 Jan 2007 18:51:49 +0100, Charles McCathieNevile  
<chaals@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.

Whether or not specifications require it to fire is independent of who  
makes the requirements regarding firing, no?

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

I'm not sure this makes much sense in the long term.

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

That would make it more clear.

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

Yes, me. Interoperability is important.

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

If there was a good reason for the change surely you want all those  
methods to behave the same way.

Anne van Kesteren
Received on Sunday, 28 January 2007 18:00:23 UTC

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